Скачать презентацию Principles for Secure E-Commerce Mark D Wood mdw kodak Скачать презентацию Principles for Secure E-Commerce Mark D Wood mdw kodak

f9c49bce0570a8a274d2897a1ea680da.ppt

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

Principles for Secure E-Commerce Mark. D. Wood (mdw@kodak. com) Principles for Secure E-Commerce Mark. D. Wood (mdw@kodak. com)

Tutorial Goals • To provide a basic understanding of – Security requirements – Cryptography Tutorial Goals • To provide a basic understanding of – Security requirements – Cryptography principles – SSL/TLS – XML-based formats and protocols • How they may be used to implement secure e-commerce ©Eastman Kodak Company, 2003 2

Security Requirements • Basic elements of providing security – Authentication – Authorization – Integrity Security Requirements • Basic elements of providing security – Authentication – Authorization – Integrity – Confidentiality – Non-repudiation • Provide the elements your application requires ©Eastman Kodak Company, 2003 3

Authentication • Verifying the identity of an entity • Requires two steps – Identification Authentication • Verifying the identity of an entity • Requires two steps – Identification – Verification • Mutual or unilateral ©Eastman Kodak Company, 2003 4

Authorization • Right of access to system resources • The authorization process determines what Authorization • Right of access to system resources • The authorization process determines what rights you have ©Eastman Kodak Company, 2003 5

Integrity • “The property that data has not been changed, destroyed, or lost” in Integrity • “The property that data has not been changed, destroyed, or lost” in an unintended manner [ISG] ©Eastman Kodak Company, 2003 6

Confidentiality • Information is only accessible to authorized parties ©Eastman Kodak Company, 2003 7 Confidentiality • Information is only accessible to authorized parties ©Eastman Kodak Company, 2003 7

Non-Repudiation • Entities cannot credibly deny previous requests or actions ©Eastman Kodak Company, 2003 Non-Repudiation • Entities cannot credibly deny previous requests or actions ©Eastman Kodak Company, 2003 8

Risks • No mechanism is 100% failproof • Identify requirements necessary for your application Risks • No mechanism is 100% failproof • Identify requirements necessary for your application and level of risk you are willing to tolerate ©Eastman Kodak Company, 2003 9

Types of Risks • Authentication: Forged credentials • Authorization: Stolen access tokens; bypassed authorization Types of Risks • Authentication: Forged credentials • Authorization: Stolen access tokens; bypassed authorization mechanisms • Integrity: Undetected tampering • Confidentiality: Undetected eavesdropping • Non-Repudiation: Credibility questions ©Eastman Kodak Company, 2003 10

Cryptography Primer • Encryption and decryption algorithms are the basis for digital security algorithms Cryptography Primer • Encryption and decryption algorithms are the basis for digital security algorithms • Higher level abstractions and mechanisms – Digital signatures – Secure transport protocols (IPSec, SSL, TLS) – Message encryption • Leveraged to provide authentication, authorization, integrity, confidentiality, nonrepudiation ©Eastman Kodak Company, 2003 11

Symmetric Cryptography • A single key is used both to encrypt and decrypt messages Symmetric Cryptography • A single key is used both to encrypt and decrypt messages • Both sender and receiver need to know the key – Key typically transmitted using an out-of-band mechanism ©Eastman Kodak Company, 2003 12

Communicating • Alice and Bob agree on session key Kab • Alice sends a Communicating • Alice and Bob agree on session key Kab • Alice sends a message to Bob: A B: {M}Kab • Bob decrypts the message • M is called the plaintext or cleartext; {M}Kab is called the ciphertext ©Eastman Kodak Company, 2003 13

Establishing the Session Key • Out-of-band channel used to establish key • Protocol used Establishing the Session Key • Out-of-band channel used to establish key • Protocol used to negotiate a shared session key • Mechanism for exchanging the key needs to be secure ©Eastman Kodak Company, 2003 14

Public Key Cryptography • Assymetric cryptography, using two keys – Public key – Private Public Key Cryptography • Assymetric cryptography, using two keys – Public key – Private key {{M}KBpub}K = M Bpriv • Computationally infeasible to compute private key from public key or vice versa ©Eastman Kodak Company, 2003 15

Communicating • Bob sends Alice his public key, KBpub • Alice encrypts message M Communicating • Bob sends Alice his public key, KBpub • Alice encrypts message M and sends it to Bob A B: {M}KBpub • Bob decrypts message M using his private key, KBpriv ©Eastman Kodak Company, 2003 16

Authentication is Critical • How does Alice know that it is Bob’s public key? Authentication is Critical • How does Alice know that it is Bob’s public key? • Need a trusted mechanism for the distribution of keys – The certification authority vouches for the authenticity of the public keys ©Eastman Kodak Company, 2003 17

Digital Signatures • Cryptographic value appended to data used to verify the data’s origin Digital Signatures • Cryptographic value appended to data used to verify the data’s origin and integrity • Example: Alice wishes to sign message M and send to Bob A B: M, {M}KApriv • Bob can verify that Alice sent M by verifying that {{M}KApriv}KApub = M ©Eastman Kodak Company, 2003 18

Hash Functions • A hash function maps strings of arbitrary length to a typically Hash Functions • A hash function maps strings of arbitrary length to a typically small, finite value • A “good” cryptographic hash function is – One-way/non-invertible (can’t determine original value from hash) – Collision-free (can’t determine another source string that maps to same hash) • Example algorithms: MD 5, SHA-1 ©Eastman Kodak Company, 2003 19

Generating Digital Signatures • Encrypting using public keys is computationally expensive • Typically, hash Generating Digital Signatures • Encrypting using public keys is computationally expensive • Typically, hash value is signed • To sign, – Alice computes h(M) – A B: M, {h(M)}KApriv • Bob verifies by computing h(M) and comparing {{h(M)}KApriv}KApub = h(M) ©Eastman Kodak Company, 2003 20

Aside: Legal Status • Digital signatures are legally binding – Federal Electronic Signatures in Aside: Legal Status • Digital signatures are legally binding – Federal Electronic Signatures in Global and National Commerce Act of 2000 – State laws – EU Directives • Case law not yet established! ©Eastman Kodak Company, 2003 21

Digital Certificate • Consists of data and a signature over the data • A Digital Certificate • Consists of data and a signature over the data • A public key certificate associates a public key with an entity • Syntaxes for certificates – X. 509 public-key certificate – PKCS#7 certificate ©Eastman Kodak Company, 2003 22

X. 509 Data Fields • • Version of X. 509 Serial Number Signature Algorithm X. 509 Data Fields • • Version of X. 509 Serial Number Signature Algorithm Issuer Validity Period Subject Attributes Public Key ©Eastman Kodak Company, 2003 23

Certification Authorities • “An entity that issues digital certificates (especially X. 509 certificates) and Certification Authorities • “An entity that issues digital certificates (especially X. 509 certificates) and vouches for the binding between the data items in a certificate” [ISG] • Browsers hard-coded to trust certain CAs ©Eastman Kodak Company, 2003 24

©Eastman Kodak Company, 2003 25 ©Eastman Kodak Company, 2003 25

Certificate Chain • Series of certificates, ending in a self-signed certificate • Typical usage Certificate Chain • Series of certificates, ending in a self-signed certificate • Typical usage – E-commerce server will have a certificate for itself – Signed by a CA ©Eastman Kodak Company, 2003 26

Example Certificate[1]: Owner: CN=example. kodak. com, OU=D&AI, O=Eastman Kodak Company, L=Rochester, ST=New York, C=US Example Certificate[1]: Owner: CN=example. kodak. com, OU=D&AI, O=Eastman Kodak Company, L=Rochester, ST=New York, C=US Issuer: OU=www. verisign. com/CPS Incorp. by Ref. LIABILITY LTD. (c)97 Veri. Sign, OU=Veri. Sign International Server CA - Class 3, OU="Veri. Sign, Inc. ", O=Veri. Sign Trust Network Serial number: 50 daa 4 e 88174 ea 478 f 4 cfa 312 d 51887 a Valid from: Sun Jan 13 19: 00 EST 2002 until: Tue Jan 14 18: 59 EST 2003 Certificate fingerprints: MD 5: 38: 37: ED: EF: 41: 2 C: DD: 12: A 6: AB: 9 B: F 9: 90: B 0: 82: 37 SHA 1: 0: F 8: 70: 7 A: 8 D: 66: 71: D 1: BC: 11: D 2: 41: 82: 5 C: 8 A: 84: 91: BE: 87: 96 ©Eastman Kodak Company, 2003 27

Example, cont. Certificate[3]: Owner: OU=www. verisign. com/CPS Incorp. by Ref. LIABILITY LTD. (c)97 Veri. Example, cont. Certificate[3]: Owner: OU=www. verisign. com/CPS Incorp. by Ref. LIABILITY LTD. (c)97 Veri. Sign, OU=Veri. Sign International Server CA - Class 3, OU="Veri. Sign, Inc. ", O=Veri. Sign Trust Network Issuer: OU=Class 3 Public Primary Certification Authority, O="Veri. Sign, Inc. ", C=US Serial number: 236 c 971 e 2 bc 60 d 0 bf 97460 def 108 c 3 c 3 Valid from: Wed Apr 16 20: 00 EDT 1997 until: Wed Jan 07 18: 59 EST 2004 Certificate fingerprints: MD 5: 18: 87: 5 C: CB: F 8: 20: 5 D: 24: 4 A: BF: 19: C 7: 13: 0 E: FD: B 4 SHA 1: 8 B: 24: CD: 8 B: 58: C 6: DA: 72: AC: E 0: 97: C 7: B 1: E 3: CE: A 4: DC: 3 D: C 6 ©Eastman Kodak Company, 2003 28

Example, cont. Certificate[2]: Owner: OU=Class 3 Public Primary Certification Authority, O= Example, cont. Certificate[2]: Owner: OU=Class 3 Public Primary Certification Authority, O="Veri. Sign, Inc. ", C=US Issuer: OU=Class 3 Public Primary Certification Authority, O="Veri. Sign, Inc. ", C=USSerial number: 70 bae 41 d 10 d 92934 b 638 ca 7 b 03 ccbabf Valid from: Sun Jan 28 19: 00 EST 1996 until: Tue Aug 01 19: 59 EDT 2028 Certificate fingerprints: MD 5: 10: FC: 63: 5 D: F 6: 26: 3 E: 0 D: F 3: 25: BE: 5 F: 79: CD: 67 SHA 1: 74: 2 C: 31: 92: E 6: 07: E 4: 24: EB: 45: 49: 54: 2 B: E 1: BB: C 5: 3 E: 61: 74: E 2 ©Eastman Kodak Company, 2003 29

Public Key Infrastructure (PKI) • “A system of CAs that perform some set of Public Key Infrastructure (PKI) • “A system of CAs that perform some set of certificate management, archive management, key management, and token management functions for a community of users in an application of asymmetric cryptography. ” [ISG] • Major CAs include Verisign, Entrust, etc. ©Eastman Kodak Company, 2003 30

Certificate Revocation • Certificates have a lifespan – Server certificates typically 1 or 2 Certificate Revocation • Certificates have a lifespan – Server certificates typically 1 or 2 years – CAs 10 to 20 years • Certificate may become compromised or lose its meaning – Need to revoke certificate – Certificate revocation lists using LDAP ©Eastman Kodak Company, 2003 31

Comparing Symmetric and Assymetric Cryptography • Public key cryptography – – Computationally intensive Requires Comparing Symmetric and Assymetric Cryptography • Public key cryptography – – Computationally intensive Requires very long keys, e. g, 2048 bits Only private key need be kept secret Keys may remain valid for long periods of time • Symmetric key cryptography – Computationally efficient – Shorter keys, e. g. , 128 bits – Keys typically have short life times, nonce keys • Public key cryptography used to establish session key; symmetric key cryptography used for actual data exchange ©Eastman Kodak Company, 2003 32

Application: Web Commerce • Problem: Customer wishes to interact with web server to place Application: Web Commerce • Problem: Customer wishes to interact with web server to place an order using a credit card – Customer needs to know the identity of the server – Customer’s credit card number, etc. , must be kept confidential – Credit card number must be reliably transmitted ©Eastman Kodak Company, 2003 33

Web Commerce Requirements • Knowledge of credit card number, expiration date, and associated name/address Web Commerce Requirements • Knowledge of credit card number, expiration date, and associated name/address is sufficient to authenticate consumer • Non-repudiation not a requirement for online orders – Traditionally not a requirement for mail-order ©Eastman Kodak Company, 2003 34

SSL – Secure Sockets Layer • Developed by Netscape, submitted to IETF • IETF SSL – Secure Sockets Layer • Developed by Netscape, submitted to IETF • IETF version is TLS 1. 0 (Transport Layer Security) • Widely implemented in browsers • Provides secure point-to-point communication, offering – Optional authentication – Data integrity – Data confidentiality ©Eastman Kodak Company, 2003 35

SSL Steps 1. Negotiate the cipher suite The set of cryptographic algorithms to be SSL Steps 1. Negotiate the cipher suite The set of cryptographic algorithms to be used 2. Authenticate server (optional, but usually done) 3. Authenticate client (optional, not usually done for e-commerce) 4. Negotiate session key 5. Send the data ©Eastman Kodak Company, 2003 36

SSL Initialization from SSL/TLS Strong Encryption: An Introduction, Apache Software Foundation ©Eastman Kodak Company, SSL Initialization from SSL/TLS Strong Encryption: An Introduction, Apache Software Foundation ©Eastman Kodak Company, 2003 37

Cipher Suites • RSA – Public key algorithm (Rivest, Shamir, Adleman) • Diffie-Hellman • Cipher Suites • RSA – Public key algorithm (Rivest, Shamir, Adleman) • Diffie-Hellman • DES – Data Encryption Standard (symmetric) • RC 2, RC 4 – Rivest encryption (symmetric) • Triple DES (symmetric) • MD 5 – Message Digest algorithm • SHA-1 Secure Hash Algorithm ©Eastman Kodak Company, 2003 38

One More Thing: HMAC • Message Authentication Code provides an integrity “checksum” • HMAC One More Thing: HMAC • Message Authentication Code provides an integrity “checksum” • HMAC is a hash function taking an additional parameter, a cryptographic key • Used to ensure the integrity of transmission A B: {M, HMAC(M)}Kab • B computes HMAC(M) directly to verify integrity ©Eastman Kodak Company, 2003 39

Impact of Using SSL • Slows communication – Hardware accelerators exist – Protocol supports Impact of Using SSL • Slows communication – Hardware accelerators exist – Protocol supports session caching, speeding up communication • Authentication – Typically authenticates server – Authenticating client requires client to have a certificate ©Eastman Kodak Company, 2003 40

Authenticating the User • E-commerce often requires sessions with authenticated users – Shopping cart Authenticating the User • E-commerce often requires sessions with authenticated users – Shopping cart experience • HTTP inherently a sessionless/stateless protocol – May need to link interactions together into a session AND – Authenticate the user ©Eastman Kodak Company, 2003 41

Authentication Trade-Offs • Most secure – Use PKI – Awkward and expensive to administer Authentication Trade-Offs • Most secure – Use PKI – Awkward and expensive to administer keys • Most basic – HTTP Basic – No security • Moderate security – HTTP Digest – Hash of username, password, server-provided nonce – Does not provide confidentiality, unless combined with SSL/TLS – Somewhat vulnerable ©Eastman Kodak Company, 2003 42

Transport Layer Security • IPSec – At the network level; transparent to applications – Transport Layer Security • IPSec – At the network level; transparent to applications – Supports transport or tunnelling modes – Useful for establishing Virtual Private Networks (e. g. , Nortel Contivity) • Easy mechanism to provide a secure channel between two business partners ©Eastman Kodak Company, 2003 43

Protocol Layering HTTP SSL TCP IPSec IP ©Eastman Kodak Company, 2003 44 Protocol Layering HTTP SSL TCP IPSec IP ©Eastman Kodak Company, 2003 44

Problems with SSL/IPSec • Point-to-point communication – Secure communication involving active intermediaries requires pairwise Problems with SSL/IPSec • Point-to-point communication – Secure communication involving active intermediaries requires pairwise SSL sessions • Does not provide non-repudiation ©Eastman Kodak Company, 2003 45

Securing Messages • Transport layer protocols secure the data stream • Endpoints don’t have Securing Messages • Transport layer protocols secure the data stream • Endpoints don’t have proof of communication for providing archivable, non-repudiation, long-term authenticity, and integrity • Message-level protocols – Allow for selective encryption – Archival/non-repudiation – Intermediaries ©Eastman Kodak Company, 2003 46

Transport-Based Security Context Requester Security Context Intermediary ©Eastman Kodak Company, 2003 Provider 47 Transport-Based Security Context Requester Security Context Intermediary ©Eastman Kodak Company, 2003 Provider 47

Message-Based Security Requester Intermediary Provider DB Security Context ©Eastman Kodak Company, 2003 48 Message-Based Security Requester Intermediary Provider DB Security Context ©Eastman Kodak Company, 2003 48

XML Signature • XML Signature defines how a digital signature may be represented in XML Signature • XML Signature defines how a digital signature may be represented in XML • Provides integrity, signer authentication • Became W 3 C Recommendation in Feb ‘ 02 • Data be signed may be part of document or in a separate document – Document may be XML, JPEG, PDF, etc. • Allows multiple signers, signing different and multiple parts – Fragment of XML document ©Eastman Kodak Company, 2003 49

XML Signature Mechanisms Enveloped XML Document Enveloping Detached Signature XML Object Signature ©Eastman Kodak XML Signature Mechanisms Enveloped XML Document Enveloping Detached Signature XML Object Signature ©Eastman Kodak Company, 2003 50

XML Signature Structure <Signature ID? > <Signed. Info> <Canonicalization. Method/> <Signature. Method/> (<Reference URI? XML Signature Structure ( ()? )+ ()? ©Eastman Kodak Company, 2003 51

2 jmj 7 l 5 r. Sw 0 y. Vb/vl. W AYk. K/YBwk= ©Eastman Kodak Company, 2003 52

<ds: Signature. Value> Fot. Jf. Id. Wj. Mg. X 5 ATSt. GQyt 6 q+86 Fot. Jf. Id. Wj. Mg. X 5 ATSt. GQyt 6 q+86 e. Bx 1 jks. Ef. LTVgm. E+r dftdw 7 w. QHCg== MIIC 9 j. CCAr. QCBDruqiow. Cw. YHKo. ZIzjg. EAw UAMGEx. Cz. AJBg. NVBAYTAk. RFMR 0 w. Gw. YDVQ QKEx. RVbml 2 {public key value} 53 ©Eastman Kodak Company, 2003

XML Issues • Canonicalization – Spacing, etc. , matters when signing/encrypting • Transforms – XML Issues • Canonicalization – Spacing, etc. , matters when signing/encrypting • Transforms – e. g. , XSLT, etc. ©Eastman Kodak Company, 2003 54

Security Considerations From the spec • “Only What is Signed is Secure” – Remember: Security Considerations From the spec • “Only What is Signed is Secure” – Remember: Transforms may remove data, etc. • “Only What is ‘Seen’ Should be Signed” – User should have seen what is signed • “ ‘See’ What is Signed” – Verifier should use only that which is signed ©Eastman Kodak Company, 2003 55

XML Encryption • Became W 3 C Proposed Recommendation Oct 3, 2002 • Allows XML Encryption • Became W 3 C Proposed Recommendation Oct 3, 2002 • Allows for or all parts of document to be encrypted – Source: Arbitrary data, XML document, XML fragment – Result: XML encryption element ©Eastman Kodak Company, 2003 56

XML Encryption Format <Encrypted. Data Id? Type? Mime. Type? Encoding? > <Encryption. Method/>? <ds: XML Encryption Format ? ? ? ? ? ? ? ©Eastman Kodak Company, 2003 57

Web Services • Web Services paradigm built on – SOAP/XML Protocol – WSDL – Web Services • Web Services paradigm built on – SOAP/XML Protocol – WSDL – UDDI ©Eastman Kodak Company, 2003 58

Securing SOAP • SOAP messages can be transmitted using SSL/TLS – Authentication using SSL-based Securing SOAP • SOAP messages can be transmitted using SSL/TLS – Authentication using SSL-based PKI (client and server certificates) – Does not provide non-repudiation, long-term archivability • SOAP payload can contain XML-Signature and/or XML Encryption content ©Eastman Kodak Company, 2003 59

WS-Security • Specification developed by IBM, Microsoft, and Verisign • Now being standardized by WS-Security • Specification developed by IBM, Microsoft, and Verisign • Now being standardized by OASIS • Adds security to SOAP messaging – Associating “security tokens” with messages – Encrypting and/or digitally signing all or part of a message • Uses XML Signature & XML Encryption ©Eastman Kodak Company, 2003 60

WS-Security Tokens • User Names (and Passwords) • Binary Security Tokens (X. 509 Certificates WS-Security Tokens • User Names (and Passwords) • Binary Security Tokens (X. 509 Certificates and Kerberos Tickets) ©Eastman Kodak Company, 2003 61

UDDI Security Features • UDDI – Universal Description, Discovery and Integration of business for UDDI Security Features • UDDI – Universal Description, Discovery and Integration of business for the Web • UDDI V 3. 0 allows for UDDI entities to be signed – Requesters can look only for signed data – Publishers can safeguard against imposters • Access to UDDI service may be secured – SSL, etc. ©Eastman Kodak Company, 2003 62

XML Firewalls • Traditional firewalls examine data at the packet level – Provided, e. XML Firewalls • Traditional firewalls examine data at the packet level – Provided, e. g. , IP-based filtering • XML firewalls examine data at the XML message level – Can provide same type of rule-driven filtering – Automatically handle authentication, etc. – Emerging new product category ©Eastman Kodak Company, 2003 63

WS-Security/Firewall Example <s: Envelope> <S: Header> <wsse: Security> … </wsse: Security> </S: Header> <S: WS-Security/Firewall Example {request} Fire wall Client ©Eastman Kodak Company, 2003 XML Firewall Server 64

Other Acroynms to Know • XKMS – XML Key Management Specification – Provides XML-based Other Acroynms to Know • XKMS – XML Key Management Specification – Provides XML-based protocols for distributing and registering public keys, enabling lighter weight clients – X-KISS – Protocol for processing XML Sig key info – X-KRSS – Protocol for registering public key info • SAML – Security Assertions Markup Language – Provides mechanism for encoding claims in XML and passing them along; enables, e. g. , 3 rd party authentication credentials to be passed ©Eastman Kodak Company, 2003 65

More Information/References • Internet Security Glossary – ftp: //ftp. isi. edu/in-notes/rfc 2828. txt • More Information/References • Internet Security Glossary – ftp: //ftp. isi. edu/in-notes/rfc 2828. txt • Handbook of Applied Cryptography – http: //www. cacr. math. uwaterloo. ca/hac/ • IBM Redbook: TCP/IP Tutorial and Technical Overview – http: //publibb. boulder. ibm. com/redbooks. nsf/Redbook. Abstracts/gg 2 43376. html? Open ©Eastman Kodak Company, 2003 66

Still More References • PKCS Standards – http: //www. rsasecurity. com/rsalabs/pkcs/ • RSA’s Cryptography Still More References • PKCS Standards – http: //www. rsasecurity. com/rsalabs/pkcs/ • RSA’s Cryptography FAQ – http: //www. rsasecurity. com/rsalabs/faq/index. html • SSL – Netscape – Sun’s JSSE documentation – The TLS spec ©Eastman Kodak Company, 2003 67

Even More Info/References • White-Hat Security Arsenal, Aviel Rubin • “Dos and Don’ts of Even More Info/References • White-Hat Security Arsenal, Aviel Rubin • “Dos and Don’ts of Client Authentication on the Web, ” Kevin Fu et al. , MIT LCS. ©Eastman Kodak Company, 2003 68

More References: XML Sig/Enc • W 3 C XML Signature & Encryption Sections – More References: XML Sig/Enc • W 3 C XML Signature & Encryption Sections – http: //www. w 3. org • “An Introduction to XML Digital Signatures, ” Ed Simon et al. – http: //www. xml. com/lpt/a/2001/08/08/xmldsig. html ©Eastman Kodak Company, 2003 69

More References: Web Services • “Security in a Web Services World: A Proposed Architecture More References: Web Services • “Security in a Web Services World: A Proposed Architecture & Roadmap, ” IBM & Microsoft • Web Services Security Core Specification (OASIS working draft; see previous versions at MS/IBM or Verisign) ©Eastman Kodak Company, 2003 70