© eastman kodak company, 2003 principles for secure e-commerce mark. d. wood ([email protected])

©Eastman Kodak Company, 2003

Principles for Secure E-CommerceMark. D. Wood ([email protected])


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


3

Security Requirements

• Basic elements of providing security– Authentication– Authorization– Integrity– Confidentiality– Non-repudiation

• Provide the elements your application requires


4

Authentication

• Verifying the identity of an entity

• Requires two steps– Identification

– Verification

• Mutual or unilateral


5

Authorization

• Right of access to system resources

• The authorization process determines what rights you have


6

Integrity

• “The property that data has not been changed, destroyed, or lost” in an unintended manner [ISG]


7

Confidentiality

• Information is only accessible to authorized parties


8

Non-Repudiation

• Entities cannot credibly deny previous requests or actions


9

Risks

• No mechanism is 100% failproof

• Identify requirements necessary for your application and level of risk you are willing to tolerate


10

Types of Risks

• Authentication: Forged credentials

• Authorization: Stolen access tokens; bypassed authorization mechanisms

• Integrity: Undetected tampering

• Confidentiality: Undetected eavesdropping

• Non-Repudiation: Credibility questions


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


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


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


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


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


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


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


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


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


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)


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!


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


23

X.509 Data Fields

• Version of X.509• Serial Number• Signature Algorithm• Issuer• Validity Period• Subject• Attributes• Public Key


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


25


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


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


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


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


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.


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


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


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


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


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


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


37

SSL Initialization

from SSL/TLS Strong Encryption: An Introduction, Apache Software Foundation


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


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


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


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


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


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


44

Protocol Layering

IP

TCP

HTTP

IPSec

SSL


45

Problems with SSL/IPSec

• Point-to-point communication– Secure communication involving active

intermediaries requires pairwise SSL sessions

• Does not provide non-repudiation


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


47

Transport-Based Security

Requester Intermediary Provider

Security Context Security Context


48

Message-Based Security

Requester Intermediary

DB

Provider

Security Context


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


50

XML Signature Mechanisms

XML Document SignatureSignature

Signature

XML Object

Object

Enveloped Enveloping Detached


51

XML Signature Structure

<Signature ID?><SignedInfo>

<CanonicalizationMethod/> <SignatureMethod/>(<Reference URI? >

(<Transforms>)? <DigestMethod> <DigestValue>

</Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)?

</Signature>


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>


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>


54

XML Issues

• Canonicalization– Spacing, etc., matters when signing/encrypting

• Transforms– e.g., XSLT, etc.


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


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


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>


58

Web Services

• Web Services paradigm built on– SOAP/XML Protocol– WSDL– UDDI


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


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


61

WS-Security Tokens

• User Names (and Passwords)

• Binary Security Tokens (X.509 Certificates and Kerberos Tickets)


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.


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


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>


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


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


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

http://www.rsasecurity.com/rsalabs/pkcs/

http://www.rsasecurity.com/rsalabs/faq/index.html


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.


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


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)

© eastman kodak company, 2003 principles for secure e-commerce mark. d. wood ([email protected])

Documents

key needs

session key kab alice

bobs public key

keyspublic keyprivate

boba b

kbpubbob decrypts message

session keyout

shared session keymechanism