Electronic Payment Systems 20 -763 Lecture 6 Digital

Скачать презентацию Electronic Payment Systems 20 -763 Lecture 6 Digital

227d789265da4a121958a651374448c3.ppt

Количество слайдов: 39

Electronic Payment Systems 20 -763 Lecture 6: Digital Certificates

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 20 -763 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 e. Commerce • 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 20 -763 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) USE SECURE HASH ALGORITHM (SHA) TO PRODUCE HASH (MESSAGE DIGEST) HASH ENCRYPT HASH USING SIGNER’S PRIVATE KEY OF MR. A SIG ELECTRONIC PAYMENT SYSTEMS 20 -763 THIS IS THE DIGITAL SIGNATURE OF MR. A ON MESSAGE M SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

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

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

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

Client Certificates ü 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 © 2001 Integrated Partners, Inc.

Other Types of 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 © 2001 Integrated Partners, Inc.

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 20 -763 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: “A 87 B 1003 9 F 60 EA 46 71 A 837 BC 1 E 07 B 371” • 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 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

ISO X. 500 Directory Standard PURPOSE: MAKE SURE NO TWO ENTITIES OR PEOPLE HAVE THE SAME NAME STANDARD FOR HIERARCHICAL DIRECTORIES RDN: RELATIVE DISTINGUISHED NAME C: ISO COUNTRY CODE O: ORGANIZATION CN: COMMON NAME EACH RDN MAY HAVE ATTRIBUTES ELECTRONIC PAYMENT SYSTEMS 20 -763 SOURCE: XCERT. COM 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 CA 2? • You may choose to trust CA if you can verify that its certificate is genuine CA’S CERTIFICATE ISSUED BY CA 2 CA CERTIFICATE HOLDER ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 HOLDER’S CERTIFICATE ISSUED BY CA COPYRIGHT © 2004 MICHAEL I. SHAMOS

Certificate Authority Hierarchy Root CA issues its own certificate! 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 ELECTRONIC PAYMENT SYSTEMS 20 -763 PCA SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Certification Path SEQUENCE OF CERTIFICATES LEADING TO A TRUST POINT, USUALLY A ROOT Self Signed Root CA Certificate Info Root CA's Private Key Root Signature Sub CA Subordinate CA Certificate Info Root CA's Private Key Root Signature Alice Certificate Info Subordinate CA's Private Key Sub. CA's Signature Text Document Alice's Private Key Alice's Signature ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS SOURCE: MARK SILVERMAN

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

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 20 -763 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 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

One-Way Authentication Alice IDA RA IDA INCLUDES A CERTIFICATE AND CERTIFICATION PATH Insecure Channel RS Challenge RA Hash Sig RS random value (Nonce) Eve IDA Encryption with Private Key IDA Bob Hash Response RA RS Hash Decryption with Public Key Sig SOURCE: ANDREAS STEFFEN, ZHW ELECTRONIC PAYMENT SYSTEMS 20 -763 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 20 -763 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 Statement • INFN (Istituto Nazionale di Fisica Nucleare) CPS RAINBOW LUNA CA 3 TRUSTED ROOT KEY SYSTEM ELECTRONIC PAYMENT SYSTEMS 20 -763 IBM S/390 SECURE CRYPTOGRAPHIC MODULE SPRING 2004 LITRONIC 440 CIPHERACCELERATOR 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 20 -763 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

Abstract Syntax Notation • ASN. 1 is widely used – e. g. all digital certificates • ASN. 1 has primitive types: BOOLEAN, INTEGER, REAL, ENUMERATED, BIT STRING, IA 5 STRING, . . . • 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

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: BOOLEAN IA 5 STRING INTEGER SEQUENCE SET 01 16 02 10 31 (8 -BIT ASCII) • The string “Customer” would be encoded as 16 08 43 75 73 74 6 F 6 D 65 72 IA 5 STRING LENGTH 8 HEX “C” ELECTRONIC PAYMENT SYSTEMS 20 -763 HEX “r” HEX “u” SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Basic Encoding Rules BBCard : : = SEQUENCE { name IA 5 String (SIZE (1. . 60)), team IA 5 String (SIZE (1. . 60)), age INTEGER (1. . 100), position IA 5 String (SIZE (1. . 60)), handedness ENUMERATED {left-handed(0), right-handed(1), ambidextrous(2)}, batting-average REAL } “Casey”, “Mudville Nine”, 32, “left field”, ambidextrous, 0. 250 (47 bytes of text) C a s e y M 302 D 1605 43617365 79160 D 4 D 4 E 696 E 65 02012016 0 A 6 C 6566 01020903 80 FE 01 (47 ELECTRONIC PAYMENT SYSTEMS 20 -763 u d v i 75647669 74206669 bytes in SPRING 2004 l l e 6 C 6 C 6520 656 C 640 A BER) COPYRIGHT © 2004 MICHAEL I. SHAMOS

ASN. 1 Definition of X. 509 Certificate “TO BE SIGNED” CERTIFICATE Certificate : : = SEQUENCE { = INTERMEDIATE (NON-ROOT) CERTIFICATE tbs. Certificate TBSCertificate, signature. Algorithm. Identifier, signature. Value BIT STRING } TBSCertificate : : = SEQUENCE { version [0] EXPLICIT Version DEFAULT v 1, serial. Number Certificate. Serial. Number, signature Algorithm. Identifier, issuer Name, validity Validity, subject Name, subject. Public. Key. Info Subject. Public. Key. Info, issuer. Unique. ID [1] IMPLICIT Unique. Identifier OPTIONAL, -If present, version shall be v 2 or v 3 subject. Unique. ID [2] IMPLICIT Unique. Identifier OPTIONAL, -If present, version shall be v 2 or v 3 extensions [3] EXPLICIT Extensions OPTIONAL -If present, version shall be v 3 }

ASN. 1 Definition of X. 509 Certificate Version : : = INTEGER { v 1(0), v 2(1), v 3(2) } Certificate. Serial. Number : : = INTEGER Algorithm. Identifier : : = SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL} Name : : = CHOICE { RDNSequence } RDNSequence : : = SEQUENCE OF Relative. Distinguished. Name : : = SET OF Attribute. Type. And. Value : : = SEQUENCE { type Attribute. Type, value Attribute. Value } Attribute. Type : : = OBJECT IDENTIFIER Attribute. Value : : = ANY DEFINED BY Attribute. Type Validity : : = SEQUENCE { not. Before Time, not. After Time } Time : : = CHOICE { utc. Time UTCTime, general. Time Generalized. Time } Unique. Identifier : : = BIT STRING Subject. Public. Key. Info : : = SEQUENCE { algorithm Algorithm. Identifier, subject. Public. Key BIT STRING } Extensions : : = SEQUENCE SIZE (1. . MAX) OF Extension : : = SEQUENCE { extn. ID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extn. Value OCTET STRING }

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

ASN. 1 Applications • Telephone billing information – Transferred Account Procedure (TAP 3) – UMTS (3 G phones) • • • X 9 financial services (checks, electronic funds transfer) Air-to-ground aircraft information Electric and gas utilities Automobile diagnostic monitoring systems Radio Frequency Identification (RFID) Biometric IDs (Proposed ANSI Standard X 9. 84) – Common Biometric Exchange File Format CBEFF • Smart cards (ISO 7816 -4) • MORE ELECTRONIC PAYMENT SYSTEMS 20 -763 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 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Major Ideas • MANY e. Commerce 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 • ASN 1. is a “hidden” method of specifying data formats, but used is many applications, including digital certificates ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS