© eastman kodak company, 2003 principles for secure e-commerce mark. d. wood (mdw@kodak.com)
Post on 28-Dec-2015
218 Views
Preview:
TRANSCRIPT
©Eastman Kodak Company, 2003
Principles for Secure E-CommerceMark. D. Wood (mdw@kodak.com)
©Eastman Kodak Company, 2003
2
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
3
Security Requirements
• Basic elements of providing security– Authentication– Authorization– Integrity– Confidentiality– Non-repudiation
• Provide the elements your application requires
©Eastman Kodak Company, 2003
4
Authentication
• Verifying the identity of an entity
• Requires two steps– Identification
– Verification
• Mutual or unilateral
©Eastman Kodak Company, 2003
5
Authorization
• Right of access to system resources
• The authorization process determines what rights you have
©Eastman Kodak Company, 2003
6
Integrity
• “The property that data has not been changed, destroyed, or lost” in an unintended manner [ISG]
©Eastman Kodak Company, 2003
7
Confidentiality
• Information is only accessible to authorized parties
©Eastman Kodak Company, 2003
8
Non-Repudiation
• Entities cannot credibly deny previous requests or actions
©Eastman Kodak Company, 2003
9
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
10
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
11
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, non-repudiation
©Eastman Kodak Company, 2003
12
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
13
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
14
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
15
Public Key Cryptography
• Assymetric cryptography, using two keys– Public key– Private key
{{M}KBpub}
KBpriv = M
• Computationally infeasible to compute private key from public key or vice versa
©Eastman Kodak Company, 2003
16
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
17
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
18
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
19
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: MD5, SHA-1
©Eastman Kodak Company, 2003
20
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
21
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
22
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
23
X.509 Data Fields
• Version of X.509• Serial Number• Signature Algorithm• Issuer• Validity Period• Subject• Attributes• Public Key
©Eastman Kodak Company, 2003
24
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
25
©Eastman Kodak Company, 2003
26
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
27
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 VeriSign, OU=VeriSign International Server CA - Class 3, OU="VeriSign, Inc.", O=VeriSign Trust Network
Serial number: 50daa4e88174ea478f4cfa312d51887a
Valid from: Sun Jan 13 19:00:00 EST 2002 until: Tue Jan 14 18:59:59 EST 2003
Certificate fingerprints: MD5: 38:37:ED:EF:41:2C:DD:12:A6:AB:9B:F9:90:B0:82:37 SHA1: 0:F8:70:7A:8D:66:71:D1:BC:11:D2:41:82:5C:8A:84:91:BE:87:96
©Eastman Kodak Company, 2003
28
Example, cont.
Certificate[3]:
Owner: OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign, OU=VeriSign International Server CA - Class 3, OU="VeriSign, Inc.", O=VeriSign Trust Network
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Serial number: 236c971e2bc60d0bf97460def108c3c3
Valid from: Wed Apr 16 20:00:00 EDT 1997 until: Wed Jan 07 18:59:59 EST 2004
Certificate fingerprints:
MD5: 18:87:5C:CB:F8:20:5D:24:4A:BF:19:C7:13:0E:FD:B4
SHA1: 8B:24:CD:8D:8B:58:C6:DA:72:AC:E0:97:C7:B1:E3:CE:A4:DC:3D:C6
©Eastman Kodak Company, 2003
29
Example, cont.
Certificate[2]:
Owner: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=USSerial number: 70bae41d10d92934b638ca7b03ccbabf
Valid from: Sun Jan 28 19:00:00 EST 1996 until: Tue Aug 01 19:59:59 EDT 2028
Certificate fingerprints:
MD5: 10:FC:63:5D:F6:26:3E:0D:F3:25:BE:5F:79:CD:67:67
SHA1: 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
©Eastman Kodak Company, 2003
30
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
31
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
32
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
33
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
34
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
35
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
36
SSL Steps
1. Negotiate the cipher suiteThe 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 key5. Send the data
©Eastman Kodak Company, 2003
37
SSL Initialization
from SSL/TLS Strong Encryption: An Introduction, Apache Software Foundation
©Eastman Kodak Company, 2003
38
Cipher Suites
• RSA – Public key algorithm (Rivest, Shamir, Adleman)
• Diffie-Hellman
• DES – Data Encryption Standard (symmetric)
• RC2, RC4 – Rivest encryption (symmetric)
• Triple DES (symmetric)
• MD5 – Message Digest algorithm• SHA-1 Secure Hash Algorithm
©Eastman Kodak Company, 2003
39
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 transmissionA B: {M, HMAC(M)}Kab
• B computes HMAC(M) directly to verify integrity
©Eastman Kodak Company, 2003
40
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
41
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
42
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
43
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
44
Protocol Layering
IP
TCP
HTTP
IPSec
SSL
©Eastman Kodak Company, 2003
45
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
46
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
47
Transport-Based Security
Requester Intermediary Provider
Security Context Security Context
©Eastman Kodak Company, 2003
48
Message-Based Security
Requester Intermediary
DB
Provider
Security Context
©Eastman Kodak Company, 2003
49
XML Signature
• XML Signature defines how a digital signature may be represented in XML
• Provides integrity, signer authentication
• Became W3C 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
50
XML Signature Mechanisms
XML Document SignatureSignature
Signature
XML Object
Object
Enveloped Enveloping Detached
©Eastman Kodak Company, 2003
51
XML Signature Structure
<Signature ID?><SignedInfo>
<CanonicalizationMethod/> <SignatureMethod/>(<Reference URI? >
(<Transforms>)? <DigestMethod> <DigestValue>
</Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)?
</Signature>
©Eastman Kodak Company, 2003
52
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<ds:Reference URI="#Body"><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>2jmj7l5rSw0yVb/vlWAYkK/YBwk=</ds:DigestValue>
</ds:Reference></ds:SignedInfo>
©Eastman Kodak Company, 2003
53
<ds:SignatureValue>FotJfIdWjMgX5ATStGQyt6q+86eBx1jksEfLTVgmE+rdftdw7wQHCg==
</ds:SignatureValue><ds:KeyInfo>
<ds:X509Data><ds:X509Certificate>
MIIC9jCCArQCBDruqiowCwYHKoZIzjgEAwUAMGExCzAJBgNVBAYTAkRFMR0wGwYDVQQKExRVbml2
</ds:X509Certificate></ds:X509Data><ds:KeyValue>
<ds:DSAKeyValue> {public key value}</ds:DSAKeyValue>
</ds:KeyValue></ds:KeyInfo>
</ds:Signature>
©Eastman Kodak Company, 2003
54
XML Issues
• Canonicalization– Spacing, etc., matters when signing/encrypting
• Transforms– e.g., XSLT, etc.
©Eastman Kodak Company, 2003
55
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
56
XML Encryption
• Became W3C 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
57
XML Encryption Format
<EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo>
<ds:KeyName>? <ds:RetrievalMethod>?
</ds:KeyInfo>? <CipherData>
<CipherValue>? <CipherReference URI?>?
</CipherData> <EncryptionProperties>?
</EncryptedData>
©Eastman Kodak Company, 2003
58
Web Services
• Web Services paradigm built on– SOAP/XML Protocol– WSDL– UDDI
©Eastman Kodak Company, 2003
59
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
60
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
61
WS-Security Tokens
• User Names (and Passwords)
• Binary Security Tokens (X.509 Certificates and Kerberos Tickets)
©Eastman Kodak Company, 2003
62
UDDI Security Features
• UDDI – Universal Description, Discovery and Integration of business for the Web
• UDDI V3.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
63
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
64
WS-Security/Firewall Example
ClientFirewall
XMLFirewall
Server
<s:Envelope> <S:Header> <wsse:Security> … </wsse:Security> </S:Header> <S:Body> {request} </S:Body></S:Envelope>
©Eastman Kodak Company, 2003
65
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., 3rd party authentication credentials to be passed
©Eastman Kodak Company, 2003
66
More Information/References
• Internet Security Glossary– ftp://ftp.isi.edu/in-notes/rfc2828.txt
• Handbook of Applied Cryptography– http://www.cacr.math.uwaterloo.ca/hac/
• IBM Redbook: TCP/IP Tutorial and Technical Overview– http://publib-b.boulder.ibm.com/redbooks.nsf/
RedbookAbstracts/gg243376.html?Open
©Eastman Kodak Company, 2003
67
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
68
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
69
More References: XML Sig/Enc
• W3C XML Signature & Encryption Sections– http://www.w3.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
70
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)
top related