ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 6: Digital Certificates

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Outline Digital signatures Identity documents Digital certificates Certificate hierarchy Certification chains Remote authentication Public key infrastructure (PKI) ASN.1 encoding of digital certificates

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Digital Signatures A handwritten signature is a function of the signer only, not the message Handwritten signatures can be copied and forged The digital equivalent of a handwritten signature would be useless in eCommerce Must be able to –Compare it with the “real” signature; AND –Must be sure it isn’t copied or forged How can A prove his identity over the Internet?

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Digital Signatures A digital signature is a function of both the signer and the message A digital signature is a digest of the message encrypted with the signer’s private key MESSAGE M (LONG) HASH SIG USE SECURE HASH ALGORITHM (SHA) TO PRODUCE HASH (MESSAGE DIGEST) ENCRYPT HASH USING SIGNER’S PRIVATE KEY PRIVATE KEY OF MR. A THIS IS THE DIGITAL SIGNATURE OF MR. A ON MESSAGE M

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Authentication by Digital Signature MESSAGE (LONG) HASH RECIPIENT USES SHA TO COMPUTE HASH RECIPIENT DECRYPTS SIG WITH SIGNER’S PUBLIC KEY MESSAGE (LONG)SIG IF HASHES ARE EQUAL, MESSAGE IS AUTHENTIC. WHY? IF ANY BIT OF M OR SIG IS ALTERED, HASH CHANGES. RECIPIENT RECEIVES SIG + MESSAGE =?

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS 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 Identity document is USELESS without a challenge Challenge: protocol for holder to prove he is the person named in the document –Photograph –Signature –Fingerprint

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Trusting Identity Documents Why does anyone trust an identity document? Depends on the issuer –Do I recognize the document? –Do I know the issuer? –Can the document be forged or alerted? –Will the challenge be effective?

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Sample Identity Documents

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 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 SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Digital Certificate Contents Serial number 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

Generating a Digital Certificate Certificate Serial Number Signature Algorithm Identifier Issuer Period of Validity Subject C=US ST=NY L=Albany O=OFT CN=John Doe Subject’s Public Key Algorithm Identifier + Key Value Message Digest Hashing Algorithm Issuer’s Private Key Signature of Issuer SOURCE: CARL SMIGIELSKI Version of Certificate Standard

Also called a personal or browser certificate Signing certificate Bound to key-pair used for digital signatures Encrypting certificate Bound to key-pair used for encryption Extensive support found in SSL/TLS (next lecture) SOURCE: CARL SMIGIELSKI Client Certificates

Root Certificates Self-signed by a Certification Authority CA Certificates For verifying signatures on issued certificates Server Certificates For use by SSL/TLS servers Software Signing Certificates For signing executable code SOURCE: CARL SMIGIELSKI Other Types of Certificates

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS 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)

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Challenge by Nonce If you’re really Shamos, you must know his private key So please encrypt this nonce with his private key: “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

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 PURPOSE: MAKE SURE NO TWO ENTITIES OR PEOPLE HAVE THE SAME NAME

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Certification Hierarchy What happens if you don’t recognize the CA in a certificate or it is not a trusted CA? Suppose CA has a certificate issued by trusted CA2? You may choose to trust CA if you can verify that its certificate is genuine CA CA2 CA’S CERTIFICATE ISSUED BY CA2 CERTIFICATE HOLDER HOLDER’S CERTIFICATE ISSUED BY CA

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS 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 CCAMCA PCA CERTIFICATE ISSUANCE Root CA issues its own certificate!

Certification Path Root CA Certificate Info Root Signature Sub CA Root Signature Subordinate CA Certificate Info Root CA's Private Key Subordinate CA's Private Key SubCA's Signature Alice Certificate Info Alice's Signature Text Document Alice's Private Key Self Signed SEQUENCE OF CERTIFICATES LEADING TO A TRUST POINT, USUALLY A ROOT SOURCE: MARK SILVERMAN

HHS Root CA NIH CIT Bob FDA CDRH Alice Bob gets cert from Alice 1. Alice's cert signed by CDRH 2. CDRH's cert signed by FDA 3. FDA's cert signed by HHS HHS is Bob's trust point, therefore Bob trust's Alice's cert SOURCE: MARK SILVERMAN Building a Certification Path

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS One-Way Remote Authentication How can Alice send a message to Bob so Bob knows that –the message is from the real Alice –the message was intended for Bob –no one has altered or replayed the message Message must include –Alice’s signature & certification path –Bob's identity –timestamp & nonce

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS One-Way Authentication Insecure ChannelAliceBob Sig Encryption with Private Key RSRS RSRS Hash Decryption with Public Key Hash Eve RSRS RSRS RSRS RSRS Challenge random value (Nonce) ID A RARA RARA Response Sig ID A RARA RARA RARA RARA Hash ID A INCLUDES A CERTIFICATE AND CERTIFICATION PATH SOURCE: ANDREAS STEFFEN, ZHW

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 RAINBOW LUNA CA3 TRUSTED ROOT KEY SYSTEM

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

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 the language ASN.1 ASN.1 is a method of encoding data so that the format can be decoded from the data itself ASN.1 is not a programming language It describes only data structures. No code, no logic. Can be used as input to a compiler to produce code

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Abstract Syntax Notation ASN.1 is widely used – e.g. all digital certificates ASN.1 has primitive types: BOOLEAN, INTEGER, REAL, ENUMERATED, BIT STRING, IA5STRING,... ASN.1 has –SET (unordered) –SEQUENCE (fixed order) of primitive types –CHOICE for selecting alternative types (integer or real) Can define new types: Month ::= INTEGER (1..12) Day ::= INTEGER (1..31) Daily-stock-volume ::= SEQUENCE SIZE (31) OF INTEGER

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Basic Encoding Rules (BER) Define how fields described in ASN.1 should be encoded Units of BER are data elements A data element is a triple TLV: { type, length, value } Some type codes: The string “Customer” would be encoded as F 6D BOOLEAN01 IA5STRING16 (8-BIT ASCII) INTEGER02 SEQUENCE10 SET 31 IA5STRING LENGTH 8 HEX “C” HEX “u” HEX “r”

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Basic Encoding Rules Content field may be primitive (value) or structured (content has subcomponents)

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Basic Encoding Rules BBCard ::= SEQUENCE { name IA5String (SIZE (1..60)), team IA5String (SIZE (1..60)), age INTEGER (1..100), position IA5String (SIZE (1..60)), handedness ENUMERATED {left-handed(0), right-handed(1), ambidextrous(2)}, batting-average REAL } “Casey”, “Mudville Nine”, 32, “left field”, ambidextrous, (47 bytes of text) C a s e y M u d v i l l e 302D D4D C6C6520 4E696E A6C C640A FE01 (47 bytes in BER)

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Using ASN.1/BER ASN.1 COMPILER ASN.1 DEFINITIONS APPLICATION PROGRAM SOURCE LANGUAGE (JAVA, C) DATA STRUCTURES APPLICATION CODE APPLICATION PROGRAM ENCODER/ DECODER (JAVA, C) COMPILER APPLICATION PROGRAM NOW READS AND WRITES DATA ACCORDING TO BER

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS ASN.1 Applications Telephone billing information –Transferred Account Procedure (TAP3) –UMTS (3G phones) X9 financial services (checks, electronic funds transfer) Air-to-ground aircraft information Electric and gas utilities Automobile diagnostic monitoring systems Radio Frequency Identification (RFID)RFID Biometric IDs (Proposed ANSI Standard X9.84) –Common Biometric Exchange File Format CBEFFCBEFF Smart cards (ISO ) MORE

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Major Ideas Digital signature = hash of message encrypted with signer’s private key. Computationally unforgeable Digital certificate = digital identity document issued by a trusted third party. Associates a public key with a real person A digital signatures without a certificate does not prove identity The holder of a certificate must be challenged to prove he knows the correct private key Certificate authorities form trust hierarchies, with certificate paths from sender to recipient, allowing verification of the trust relationship

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Major Ideas MANY eCommerce applications do not require verification of identity, but only verification of authorization Digital certificates are useful when identity must be proven or when interacting with multiple parties not known in advance A long-term relationship between two parties does not require a digital certificate; a password is often (not always) sufficient ASN1. is a “hidden” method of specifying data formats, but used is many applications, including digital certificates

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Q A &