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

08cd2595766ff64ec743a6832b46a776.ppt

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

Electronic Payment Systems 20 -763 Lecture 7 Digital Certificates Electronic Payment Systems 20 -763 Lecture 7 Digital Certificates

Digital Certificate • A digital identity document binding a public-private key pair to a 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 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

ISO X. 500 Directory Standard STANDARD FOR HIERARCHICAL DIRECTORIES RDN: RELATIVE DISTINGUISHED NAME C: 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 20 -763 ELECTRONIC PAYMENT SYSTEMS SOURCE: XCERT. COM FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

X. 509 Version 2 Certificate VERSION # OF X. 509 UNIQUE # ASSIGNED BY X. 509 Version 2 Certificate VERSION # OF X. 509 UNIQUE # ASSIGNED BY CA EXAMPLES: MD 5 RSA, sha 1 RSA USUALLY A DOMAIN NAME EXAMPLES: RSA SOURCE: FORD & BAUM, SECURE ELECTRON IC COMMERCE 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

VISA 768 -bit Public Key 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © VISA 768 -bit Public Key 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Digital Certificate Verification • Is the CA trusted? – If not, follow the certificate 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 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

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

Digital Certificate Verification • Possession of a digital certificate proves nothing • Why? Digital 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. 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Authentication by Digital Certificate • • • Possession of a digital certificate means nothing 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

Certification Paths • Alice has a certificate issued by authority D • To verify 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) 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

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

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

Authentication • • B checks IB to make sure he is the intended recipient 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 AT THIS POINT, B HAS AUTHENTICATED A. THIS IS “ONE-WAY AUTHENTICATION” • B can send A an authentication token so A will know that B is authentic IF A AND B AUTHENTICATE EACH OTHER, WE HAVE “TWO-WAY AUTHENTICATION” 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Public Key Infrastructure (PKI) • Digital certificates alone are not enough to establish security 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 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Functions of a Public Key Infrastructure (PKI) • Generate public/private key pairs • Identify 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 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Corporate PKI Components SOURCE: INFOSEC ENGINEERING 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT Corporate PKI Components SOURCE: INFOSEC ENGINEERING 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Certification Practice Statement • Satement by a CA of the policies and procedures it 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 CHRYSALIS LUNA CA 3 TRUSTED ROOT KEY SYSTEM 20 -763 ELECTRONIC PAYMENT SYSTEMS IBM S/390 SECURE CRYPTOGRAPHIC MODULE FALL 2001 LITRONIC 440 CIPHERACCELERATOR COPYRIGHT © 2001 MICHAEL I. SHAMOS

Certificate Revocation List • Online list of revoked certificates • View Verisign CRL • Certificate Revocation List • Online list of revoked certificates • View Verisign CRL • Verisign CRL usage agreement 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Format of Digital Certificates • Certificates contain many fields, must be read by computers 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

ASN. 1 Definition of X. 509 Certificate “TO BE SIGNED” CERTIFICATE Certificate : : 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 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 }

Basic Encoding Rules • Content field may be primitive (value) or structured (content has Basic Encoding Rules • Content field may be primitive (value) or structured (content has subcomponents) Person : : = SET { name IA 5 String, age INTEGER female BOOLEAN }. BER encoding (in hex) of the instance {“Maggie”, 4, TRUE}: SET 31 0 E LENGTH OF CONTENT (BYTES) 16 06 CODE FOR IA 5 STRING M a g g i e 4 D 41 E 7 69 65 LENGTH OF “Maggie” 20 -763 ELECTRONIC PAYMENT SYSTEMS DATA 02 CODE FOR I NTEGER FALL 2001 01 LENGTH OF INTEGER 4 04 01 CODE FOR BOOLEAN TRUE 01 FF LENGTH OF BOOLEAN COPYRIGHT © 2001 MICHAEL I. SHAMOS

Signed Document Markup Language (SDML) • Designed by Financial Services Technology Consortium (FSTC) for 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 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

" src="https://present5.com/presentation/08cd2595766ff64ec743a6832b46a776/image-24.jpg" alt="SDML Example HEADER ACTION BLOCK ATTACHMENT BLOCK DIGITAL SIGNATURE BLOCK " /> SDML Example HEADER ACTION BLOCK ATTACHMENT BLOCK DIGITAL SIGNATURE BLOCK act 1true1. 0 sampleprocess TEXT OF DOCUMENT GOES HERE att 0123 This is a sample attachment MESSAGE DIGEST OF sig 7true1. 0 ACTION BLOCK act 1 278 B 7 F 348 EECE 3822 A 48 C 4 D 197 FD 5 B 920001 C 2 E 8 att 0123 BC 59 D 2 FE 5566 F 506910 C 5020 B 628 E 4136 E 1 C 6 B 39 9 D 9 BC 5 AA 75 MESSAGE DIGEST OF cert-11111 -00000001 ATTACHMENT BLOCK sha/dsa us DIGITAL SIGNATURE 2489 E 1 E 376 F 5 CD 823274010 B 0 A 6028 EA 3 F 2763 F 2: 290 B 95 F 8 F 02 CF 66 16 B 9 C 3 A 03 DF 0 B 50295 A 162295 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

SDML Example CERTIFICATE OF SIGNER <cert> <blkname>cert-11111 -00000001<crit>true<vers>1. 0<certtype>x 509 v 1 <certissuer>/C=US/ST=NY/O=FSTC/OU=NYCA/<certserial>1 <certdata> SDML Example CERTIFICATE OF SIGNER cert-11111 -00000001true1. 0x 509 v 1 /C=US/ST=NY/O=FSTC/OU=NYCA/1 308201 F 0308201 B 0020101300906072 A 8648 CE 380403303 D 310 B 300906035504061302555331 0 B 3009060355040813024 D 44310 E 300 C 060355040 A 130542414 E 4 B 413111300 F 060355040 B 13. . . 910 CE 325 DB 7 E cert-11111 true 1. 0 x 509 v 1 /C=US/O=FSTC/OU=FSTC CA/1 308201 DF 3082019 F 020101300906072 A 8648 CE 380403303 F 310 B 3009060355040 12314 BDBEB 300906072 A 8648 CE 380403032 F 00302 C 021456 A 0 A 84 E 997 EB 0772 DD 592753338 E 9 D 65 B 0795750214269 AAE 91801 D 9 E 80 B 8004 A 89225 E 27915044 EA 40 20 -763 ELECTRONIC PAYMENT SYSTEMS CERTIFICATE OF ISSUER OF SIGNER’S PUBLIC KEY FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Cryptographic Notation { A, B, C, D } means strings A, B, C and 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 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Q&A 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS Q&A 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS