ELC 200 Day 24

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 2 Day 24 Agenda Student Evaluations Should be progressing on Framework –Scheduling the Frame work presentations will be done Friday May 3 or May 6 Quiz 4 (last) will be April 29 Chap 13, 14, & 15 Assignment 8 DUE –One more, will count best 8 out of 9 –Assignment 9 will be given out Friday Lecture/Discuss Encryption

Chapter 14 Encryption: A Matter Of Trust

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 4 OBJECTIVES What is Encryption? Basic Cryptographic Algorithm Digital Signatures Major Attacks on Cryptosystems Digital Certificates Key Management Internet Security Protocols and Standards Government Regulations

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 5 WHAT IS ENCRYPTION? Based on use of mathematical procedures to scramble data to make it extremely difficult to recover the original message Converts the data into an encoded message using a key for decoding the message

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 6 Example Key is add two letters Encode –H -> J –E -> G –L -> N –O -> Q JGNNQ is encrypted code for HELLO

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 7 WHAT DOES ENCRYPTION SATISFY? Authentication Integrity Nonrepudiation Privacy

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 8 Cryptographic System Privacy Authentication Message Integrity Nonrepudiation Anti-Replay Protection Client PC with Cryptographic System Software Server with Cryptographic System Software Secure Communication Provided Automatically Source: Ray Panko, Corporate Computer and Network Security Copyright 2004 Prentice-Hall

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 9 BASIC CRYPTOGRAPHIC ALGORITHM Secret Key –The sender and recipient possess the same single key Public Key –One public key anyone can know to encrypt –One private key only the owner knows to decrypt –Provide message confidentiality –Prove authenticity of the message of originator

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 10 Secret Key Encryption for Confidentiality Network Plaintext “Hello” Encryption Method & Key Ciphertext “ ” Symmetric Key Ciphertext “ ” Plaintext “Hello” Decryption Method & Key Same Symmetric Key Interceptor Party A Party B Note: A single key is used to encrypt and decrypt in both directions. Source: Ray Panko, Corporate Computer and Network Security Copyright 2004 Prentice-Hall

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 11 Public Key Encryption for Confidentiality Party A Party B Decrypt with Party A’s Private Key Encrypt with Party A’s Public Key Encrypt with Party B’s Public Key Decrypt with Party B’s Private Key Encrypted Message Encrypted Message Source: Ray Panko, Corporate Computer and Network Security Copyright 2004 Prentice-Hall

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 12 COMMON CRYPTOSYSTEMS RSA Algorithm –Most commonly used but vulnerable Data Encryption Standards (DES) –Turns a message into a mess of unintelligible characters 3DES RC4 International Data Encryption Algorithm (IDEA)

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 13 RSA HACK Source: E-Week July 14, 2002 took 1,757 days (almost 5 years) A worldwide team of volunteers, using spare computing power, found the secret key for a message encrypted with the RC5-64 cipher, winning a $10,000 prize and, they say, casting some doubt on the security of messages protected by the cipher. Distributed.net, a collection of more than 331,000 volunteers who lent their machines' idle processing power to the effort, solved the challenge posed in 1997 by RSA Laboratories, the research arm of RSA Security Inc. It took nearly four years, a search through 15,769,938,165,961,326,592 keys and processing power roughly equivalent to nearly 46,000 2GHz AMD Athlon machines for the team to find the correct key. The plaintext message that the key unlocked was: "Some things are better left unread." A 450MHz Pentium III machine in Japan found the key on July 14, but a technical glitch prevented the Distributed.net team from realizing they had the correct key until Aug. 12. The team's organizers said their effort should not only prove the effectiveness of distributed computing efforts in solving large problems but also cause people to think twice before using the 64-bit RC5 cipher to encrypt some data. "While it's debatable that the duration of this project does much to devalue the security of a 64-bit RC5 key…we can say with confidence that RC5 is not an appropriate algorithm to use for data that will still be sensitive in more than several years' time," the team said in a statement.

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 14 DIGITAL SIGNATURES Transform the message signed so that anyone who reads it can be sure of the real sender A block of data representing a private key Serve the purpose of authentication

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 15 Digital Signature for Message- by-Message Authentication To Create the Digital Signature: 1. Hash the plaintext to create a brief message digest; this is NOT the Digital Signature. 2. Sign (encrypt) the message digest with the sender’s private key to create the digital signature. 3. Transmit the plaintext + digital signature, encrypted with symmetric key encryption. Plaintext MD DS Plaintext Hash Sign (Encrypt) with Sender’s Private Key

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 16 Digital Signature for Message- by-Message Authentication 4. Encrypted with Session Key DSPlaintext Sender Receiver

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 17 Digital Signature for Message- by-Message Authentication To Test the Digital Signature 5. Hash the received plaintext with the same hashing algorithm the sender used. This gives the message digest. 6. Decrypt the digital signature with the sender’s public key. This also should give the message digest. 7. If the two match, the message is authenticated. Received Plaintext MD DS MD 5.6. Hash Decrypt with True Party’s Public Key 7. Are they equal?

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 18 MAJOR ATTACKS ON CRYPTOSYSTEMS Chosen-plaintext Attack –Insert know text into the system and analyze Ciphertext Known-plaintext Attack –Assume certain properties of plaintext to analyze Ciphertext Ciphertext-only Attack –Guessing game –Make use of certain mathematical properties off the crypto system Third-party Attack –Man in the middle

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 19 Replay Attacks –Retransmit an intercepted message –Message is encrypted so that replay attacker cannot read it Why Replay Attacks –Repetition might work—for instance, replaying an encrypted username and password might result in access to a poorly designed system

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 20 Public Key Deception Impostor “I am the True Person.” “Here is TP’s public key.” (Sends Impostor’s public key) “Here is authentication based on TP’s private key.” (Really Impostor’s private key) Decryption of message from Verifier encrypted with Imposter’s public key, so Impostor can decrypt it Verifier Must authenticate True Person. Believes now has TP’s public key Believes True Person is authenticated based on Impostor’s public key “True Person, here is a message encrypted with your public key.” Critical Deception

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 21 DIGITAL CERTIFICATES An electronic document issued by a certificate authority (CA) to establish a merchant’s identity by verifying its name and public key Includes holder’s name, name of CA, public key for cryptographic use, duration of certificate, the certificate’s class and ID

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 22 Digital Signature and Digital Certificate in Authentication Digital Certificate Authentication Public Key of True Party Signature to Be Tested with Public Key of True Party Digital Signature

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 23 CLASSES OF CERTIFICATES Class 1 –Contains minimum checks on user’s background –Simplest and quickest Class 2 –Checks for information e.g. names, SSN, date of birth –Requires proof of physical address, etc.

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 24 CLASSES OF CERTIFICATES (Cont’d) Class 3 –You need to prove exactly who you are and you are responsible –Strongest Class 4 –Checks on things like user’s position in an organization in addition to class 3 requirements

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 25 KEY MANAGEMENT Key Generation and Registration Key Distribution Key Backup / Recovery Key Revocation and Destruction

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 26 THIRD-PARTY SERVICES Public Key Infrastructure –Certification Authority –Registration Authority –Directory Services Notary Services Arbitration Services

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 27 Public Key Infrastructure (PKI) with a Certificate Authority Create & Distribute (1)Private Key and (2) Digital Certificate 4. Certificate for Lee 3. Request Certificate for Lee 5. Certificate for Lee 6. Request Certificate Revocation List (CRL) 7. Copy of CRL Verifier (Brown) Applicant (Lee) Verifier (Cheng) Certificate Authority PKI Server

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 28 INTERNET SECURITY PROTOCOLS & STANDARDS Web Application –Secure Socket Layer (SSL) –Secure Hypertext Transfer Protocol (S-HTTP) E-Commerce –Secure Electronic Transaction (SET) –PGP –S/MIME

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 29 SSL Operates between application and transport layers Most widely used standard for online data encryption Provide services: –Server authentication –Client authentication –Encrypted SSL connection

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 30 SSL/TLS Operation Protects All Application Traffic That is SSL/TLS-Aware SSL/TLS Works at Transport Layer Applicant (Customer Client) Verifier (Merchant Server)

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 31 SSL/TLS Operation Applicant (Customer Client) Verifier (Merchant Server) 1. Negotiation of Security Options (Brief) 2. Merchant Authenticates Self to Customer Uses a Digital Certificate Customer Authentication is Optional and Uncommon

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 32 SSL/TLS Operation Applicant (Customer Client) Verifier (Merchant Server) 3. Client Generates Random Session Key Client Sends Key to Server Encrypted with Public Key Encryption 4. Ongoing Communication with Confidentiality and Merchant Digital Signatures

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 33 S-HTTP Secure Web transactions Provides transaction confidentiality, integrity and nonrepudiation of origin Able to integrate with HTTP applications Mainly used for intranet communications Does not require digital certificates / public keys

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 34 SET One protocol used for handling funds transfer from credit card issuers to a merchant’s bank account Provide confidentiality, authentication and integrity of payment card transmissions Requires customers to have digital certificate and digital wallet

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 35

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 36 PGP Encrypts the data with one-time algorithm, then encrypts the key to the algorithm using public-key cryptography Supports public-key encryption, symmetric-key encryption and digital signatures Supports other standards, e.g. SSL Free from MIT – Phil Zimmerman –

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 37 S/MIME Provides security for different data types and attachments to s Two key attributes: –Digital signature –Digital envelope Performs authentication using x.509 digital certificates

Awad –Electronic Commerce 2/e © 2004 Pearson Prentice Hall 38 GOVERNMENT REGULATIONS National Security Agency (NSA) National Computer Security Center (NCSC) –Rainbow BooksRainbow Books National Institute of Standards and Technology (NIST)National Institute of Standards and Technology (NIST) Office of Defense Trade Controls (DTC)Office of Defense Trade Controls Department of Homeland Security

Chapter 14 Encryption: A Matter Of Trust