© Eastman Kodak Company, 2003 Principles for Secure E-Commerce Mark. D. Wood (mdw@kodak.com)

©Eastman Kodak Company, 2003

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

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

Security Requirements

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

• Provide the elements your application requires

Authentication

• Verifying the identity of an entity

• Requires two steps– Identification

– Verification

• Mutual or unilateral

Authorization

• Right of access to system resources

• The authorization process determines what rights you have

Integrity

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

Confidentiality

• Information is only accessible to authorized parties

Non-Repudiation

• Entities cannot credibly deny previous requests or actions

• No mechanism is 100% failproof

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

Types of Risks

• Authentication: Forged credentials

• Authorization: Stolen access tokens; bypassed authorization mechanisms

• Integrity: Undetected tampering

• Confidentiality: Undetected eavesdropping

• Non-Repudiation: Credibility questions

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

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

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

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

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

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

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

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

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

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)

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!

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

X.509 Data Fields

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

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

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

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

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

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

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.

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

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

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

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

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

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

SSL Initialization

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

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

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

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

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

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

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

Protocol Layering

Problems with SSL/IPSec

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

intermediaries requires pairwise SSL sessions

• Does not provide non-repudiation

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

Transport-Based Security

Requester Intermediary Provider

Security Context Security Context

Message-Based Security

Requester Intermediary

Provider

Security Context

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

XML Signature Mechanisms

XML Document SignatureSignature

Signature

XML Object

Object

Enveloped Enveloping Detached

XML Signature Structure

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

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

</Signature>

<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>

<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>

XML Issues

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

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

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

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

XML Encryption Format

<ds:KeyName>? <ds:RetrievalMethod>?

</ds:KeyInfo>? <CipherData>

<CipherValue>? <CipherReference URI?>?

</CipherData> <EncryptionProperties>?

</EncryptedData>

Web Services

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

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

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

WS-Security Tokens

• User Names (and Passwords)

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

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.

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

WS-Security/Firewall Example

ClientFirewall

XMLFirewall

Server

<s:Envelope> <S:Header> <wsse:Security> … </wsse:Security> </S:Header> <S:Body> {request} </S:Body></S:Envelope>

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

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

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

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.

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

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 (mdw@kodak.com)

Documents

MDW Over The Years

CHICAGO MIDWAY INTL(MDW) AIRPORT DIAGRAM

Sheena Matheiken Uniform Project | MDW August 2011

C28x Delfino MDW 8-1

EASTMAN NAIA CELLULOSIC FIBER - Eastman Chemical Company · 2020-02-11 · CHEMICAL USE Naia ™ is responsibly ... Eastman Chemical Company (“Eastman”) and its subsidiaries make

MDW Part 150 Update - April 2013 - Airport Sites

Automation - · PDF fileAutomation Miniature Circuit-Breakers MDW and MDWH ... MDW-C6 6 A C 3 5 MDW-C10 10 A C 3 5 MDW-C16 16 A C 3 5 MDW-C20 20

MDW Part 150 Update - April 2013

MDW Boulder April '11 | Alessendra Lariu_Changing Your Organization

Afp2009 conference mdw tpcc rev 10-16-14

MDW NY | Scott Prindle_The Role of Creative Technologist

MDW NY | Michael Tabtabai_Great Digital Creative Ideas

Nationalim mdw

May 9, 2005 Andrew C. Gallagher1 CRV2005 Using Vanishing Points to Correct Camera Rotation Andrew C. Gallagher Eastman Kodak Company andrew.gallagher@kodak.com

Eastman Overman - Adventure Cycling Association & Overman George Eastman in 1890, photographed by Frederick F. Church aboard the S.S. Gallia. G eorge Eastman, the founder of Eastman

EASTMAN LIGHT WEIGHT ROUND KNIVES - Amazon S3s3.amazonaws.com/RFSupply/Eastman+Small+Round+Knife.pdf · EASTMAN LIGHT WEIGHT ROUND KNIVES EASTMAN DEPENDABILITY, EASTMAN QUALITY AND

Martin D. Weinberg UMass Astronomy astron100h-mdw ...courses.umass.edu/astron100h-mdw/lectures/lec03.pdfGreek cosmology Celestial sphere Ptolemy Geocentric theory Distance to Sun Size

Eastman Collection

Eastman SAIB and Eastman Sustane SAIB · Eastman SAIB . and Eastman . Sustane ™ SAIB (sucrose acetate isobutyrate) for cosmetics and. personal care

WINDOWS: Pocket Video Camera - kodak.com