Security and Internet Commerce

1. Security and Internet Commerce Chapter 27

2. Security in Transaction Systems • Security is essential in many transaction processing applications • Authentication • Is the user who he says he is? • Authorization • What is an authenticated user allowed to do? • Only cashiers can write cashier’s checks • Only faculty members can assign grades

3. Security on the Internet • Security is particularly important on the Internet • Interactions are anonymous, hence authentication of servers and users is important • Eavesdroppers can listen to conversations • Credit card numbers can be stolen • Messages can be altered • Encryption used to increase security

4. Encryption • Protect information: • Stored in a file • Transmitted between sites • Against intruders: • Passive intruder: eavesdrops and copies information • Active intruder: modifies or resends information

5. Model of an Encryption System Encryption key Decryption key sender receiver Encryption algorithm Decryption algorithm ciphertext plaintext plaintext insert, intercept intruder copy

6. Notation • For encryption ciphertext = Ksender[plaintext] • For encryption followed by decryption plaintext=Kreceiver[Ksender[plaintext]]

7. The Encryption Algorithm • It is assumed that the encryption algorithm is common knowledge and is known to all intruders • The only secret is the decryption key • Since one approach to cracking an encryption system is to try all possible keys, the longer the key the more secure the system • Two kinds of cryptography: • Symmetric cryptography Ksender = Kreceiver • Asymmetric cryptography Ksender  Kreceiver

8. Symmetric Cryptography • Same key used for encryption and decryption M = K[K[M]] • Both sender and receiver must know key • Computationally efficient (compared with asymmetric cryptography)

9. Symmetric Cryptography • Block cipher • Plaintext is divided into fixed sized blocks, which are separately encrypted • Types of block cipher: • Substitution cipher • Each plaintext block is replaced by another: abc  xza, def  tyy, ghi  rew, ... • Transposition cipher • The characters within a block are rearranged: abc  bca, def  efd, ghi  hig, ...

10. Block Cipher Attacks • Frequency analysis attack: • Frequency of blocks in plaintext compared with frequency of blocks in ciphertext; blocks with similar frequency are matched • Problem: Frequency analysis of plaintext can be performed accurately when block size is small • Solution: use large block size • Problem: The longer the stream of ciphertext, the more accurate ciphertext block frequency can be measured • Solution: change keys often

11. Data Encryption Standard (DES) plaintext • An ANSI standard symmetric cipher widely used by banks, etc. • Product cipher : • Sequence of stages • Each stage is a substitution or transposition cipher • Block size = 64 bits; key size = 56 bits • Problem: Key size too small; hence easy to crack ciphertext

12. Asymmetric Public Key Cryptography • Each user, U, has a pair of related keys: KuPub and KuPri • Different keys used for encryption and decryption M = KuPri[KuPub[M]] • Encryption key, KuPub, is public • Decryption key, KuPri, is private • Anyone can send U a message by encrypting with KuPub • Only U can decrypt it, using Kupri

13. Public Key Cryptography • Current systems based on Rivest, Shamir, Adelman (RSA) algorithm • Computationally expensive for extended exchange of data • Often used to implement a variety of security protocols that involve encrypting only a few messages

14. The RSA Algorithm • Pick two large random primes p and q • Let N = p*q • Pick a large integer d that is relatively prime to (p-1)*(q-1) • Find the integer e such that e*d 1 (mod (p-1)*(q-1)) • Encryption key is (e, N). To encrypt C = M e (mod N) • Decryption key is (d, N). To decrypt M = C d (mod N)

15. Digital Signatures • Digital Signatures can be used for • Proof of authorship • Non-repudiation by author • Important for many Internet applications • Based on public key cryptography • Current systems use RSA algorithm

16. Digital Signatures --Basic Idea • Roles of public and private keys can be reversed KPub[KPri[M]] = M • U encrypts message with its private key: KuPri[M] • Anyone can decrypt message with U’s public key: KuPub[KuPri[M]] • If decryption produces an intelligible message, only U could have created it

17. Signatures and a Message Digest • Problem: It is computationally expensive to encrypt an entire message with KPri[M] • Solution: Encrypt a message digest, f(M) |f (M) | << |M | • Example: hash of M • Signature is KPri[f(M)] • Complete signed message is (M, KPri[f(M)])

18. Verifying Signatures • To verify a signed document, (M, KPri[f(M)]) • Compute message digest, f, of first part, • Decrypt second part using KPub, and • Compare • Security depends on: • f( ) must be a one-way function: Given y, it is not feasible to find an x, such that y=f(x) • Hence, a different message, M , cannot be found to which KPri[f(M)] can be attached • No replay attack

19. One-Way Function • Over the range of possible messages, all digests are equally likely. • If f maps a large percentage of messages to the same digest, it may be easy to find an Msuch that f(M) = f(M) • If any bit of M changed, each bit of f(M) has a 50% chance of being reversed • Guards against the possibility that closely related messages have the same digest

20. One-Way function M1, M2, M3 M4, M5, M6 M7, M8, M9 f f f v1 v2 v3 Sets have roughly equal size. Elements of a set are unrelated.

21. Replay Attack • Problem: Intruder copies the message and then resends it to receiver • Solution: Include unique timestamp (or sequence number) in message. Receiver keeps timestamps of recently received messages and does not accept a duplicate

22. Digital Signature • Receiver can verify who sent M • Receiver can be sure that M has not been changed in transit (integrity) • Sender cannot deny having sent M (non-repudiation) • Note: M is sent in the clear and can be read by an intruder • If security it needed, M can be encrypted with another key

23. Key Distribution and Authentication • How do two processes agree on the key(s) they will use to encrypt messages? • How can a process be sure that it reaches agreement with the right process? • How does server know which client it is communicating with? • How can client be sure that it is communicating with intended server?

24. Key Distribution and Authentication • Key distribution and authentication are related and dealt with in the same protocol • Since protocol involves the exchange of only a few messages, it can use symmetric or asymmetric techniques • Data exchange (after protocol completes) generally uses symmetric encryption • TP monitors often provide modules that implement key distribution and authentication

25. Symmetric Key Distribution and Session Keys • Solution 1: Assign symmetric key, KP, to each process, P. Each communication session between P and another processuses KP • Problem 1: Any process that can communicate with P can decode all communication with P • Solution 2: Session keys • A new symmetric key is created for each session • Key discarded when session completed

26. Kerberos • Developed at MIT as middleware to be used in distributed systems • Goals: • Authenticate a client to a server • Distribute a session key for subsequent data exchange between the client and the server • Uses symmetric cryptography to distribute a symmetric session key

27. Key Server • Kerberos uses a key server, KS: a trusted third party responsible for distributing keys • Each client, C, or server, S, registers a symmetric key, KC,KS or KS,KS with KS • KC,KS is a one-way function of C’s password, hence it need not be stored on the client machine • KC,KS known only to C and KS; KS,KS known only to S and KS • C and S can communicate securely with KS

28. Kerberos Protocol: Tickets • (M1) C sends (C, S) to KS in the clear asking KS for a ticket that C can use to communicate with S • (M2) KS sends to C : KC, KS[KSess C-S , S, LT] --- C can decrypt this KS, KS[KSess C-S , C, LT] --- The ticket; C cannot decrypt this where: • KSess C-S is a new, randomly created session key • LT is the lifetime of the ticket

29. Kerberos Protocol: Authenticators • When C receives M2, it • Decrypts first part to obtain KSess C-S • Saves ticket until it wants to invoke S • (M3) When C wants service from S it sends: • Ticket • A newly created authenticator, KSess c-s[C, TS] • TS is a timestamp • Arguments of invocation encrypted with KSess C-S

30. Kerberos Protocol • On receiving M3, S: • Decrypts ticket using KS, KS to determine KSess C-S • Decrypts authenticator using KSess C-S • Checks that authenticator is live (TS is within LT) • Checks that authenticator has not been used before • S keeps a list of live authenticators that it has received • C is now authenticated to S • (M4) S performs requested serviceand returns results to C encrypted with KSess C-S • Only C can decrypt M4 since it is the only process (other than S) that knows KSess C-S

31. The Sequence of Message in Kerberos KS C: KC,KS S:KS,KS M1: (C, S) PC M2: (ticket,…) C M3: (ticket, authenticator, arguments) M4: results S

32. Possible Attacks • Intruder, I, copies ticket from M2 and tries to use it with an authenticator it creates • Not possible since I does not know KSess C-S • I copies M3 and later replays it • Not possible since authenticator is on S’s list • I intercepts M3 and uses ticket and authenticator for its own service invocation • Not possible if arguments encrypted with KSess C-S

33. Possible Attacks • I obtains a ticket for S from KS and later pretends to be C (by sending C in authenticator) • Not possible since I (not C) is in the ticket • I intercepts M1 and sends (C,I) instead; KS returns to C a ticket for I (instead of S) • Goal: fool C into sending M3 using a session key I knows. I can copy M3 and decrypt C’s arguments. • Not possible since I (not S)is in M2

34. Kerberos Protocol: Single Sign-on • Servers often do their own authentication, maintain their own set of user passwords • Problem: Interactions involving multiple servers involve multiple passwords • Goal: User supplies a single password; servers do not do authentication or keep user passwords • Solution: C • Authenticates itself once to authentication server, AS • Gets server tickets from ticket granting server, TGS, on demand.

35. Kerberos Protocol: Ticket-Granting Server • AS sends to C KC, AS[KSess C-TGS , TGS, LT] - session keyfor TGS KTGS, AS[KSess C-TGS , C, LT] - tkt for service from TGS • When C wants to invoke S, it sends to TGS: • tkt (encrypted with KTGS, AS) • An authenticator (encrypted with KSess C-TGS) • Arguments (S), (encrypted with KSess C-TGS)

36. Kerberos Protocol Ticket-Granting Server • TGS creates a new session key, KSess C-S, and sends to C KSess,C-TGS[KSess C-S , S, LT] - session key for S KS, AS[KSess C-S, C, LT] - ticket for S • C and S then proceed as before

37. Nonce • Problem: P1 and P2 share a session key, KSess. P1 sends M1 to P2and gets M2 back. • How can P1 be sure that M2 came from P2? • I might: • Send a random string that P1 decrypts to another random string that looks like a correct response • Replay an earlier message sent by P1 , encrypted with KSess , that is a possible response (P1is not a server that maintains a list of timestamps)

38. Nonce • Solution: Include a nonce, N, in M1 • A random string generated by P1 • Long enough so that I cannot guess it • If M2 contains N+1 then it can only have been generated by P2 and it cannot be a replay

39. Authorization • Assuming client has been authenticated, which of S’s operations is it allowed to perform? • An access control list storesthis information at S • One entry for each user or user group • Entry = (user Id, access bits); each access bit corresponds to an operation that S exports • Each server provides an authorization policy implemented in module called reference monitor provided by TP monitor • Responsible for constructing, retrieving, and interpreting access control lists

40. Authenticated RPC • Implement authentication in the rpc stubs • When a client wants to access a server, it invokes the client stub • Authentication and key exchange are performed by the stubs and the security server (e.g., Kerberos) • Security server participates in authorization by recording user Ids, group membership

41. Authenticated RPC Security server API Client stub client API Server stub server

42. Internet Commerce • Security particularly important on Internet • Authentication • Because impersonation is easy • We are now interested in authenticating the server to the client as well as the client to the server • Encryption • Because eavesdropping is easy • A higher level of suspicion exists on Internet • Interactions are not face-to-face • Easy to make impressive looking Web sites

43. Secure Sockets Layer Protocol (SSL) • Developed by Netscape • For authentication and key distribution over the Internet • Particularly authentication of a server to a client represented by a browser • Are you really sending your credit card number to Macy’s?

44. Certificates • A server, S, that wants to be authenticated registers with a certification authority(CA) • CA is a trusted third party • To obtain a certificate, S sends to CA, in the clear, its name, its URL, and its public key (among other items) • CA uses a number of means to satisfy itself that the party that requested the certificate is, in fact, who it claims to be • CA generates a certificate for S • Certifies the association between S’s name (Macy’s) and S’s public key

45. Certificates • A certificatecontains (among other items) S’s name, URL, and public key • CA signs the certificate with its private key and sends it to S • CA has certified the correctness of S’s name, public key, and URL by its signature on the certificate • CA’s public key is well-known • Stored in all browsers • All browsers contains the public keys of a number of CAs that the browser user agrees to accept • S can then distribute copies of the certificate to clients • Client can be sure that the public key in the certificate corresponds to the server named in certificate • Solves the key distribution problem in the asymmetric case

46. Secure Socket Layer Protocol-- SSL • A session-oriented protocol • (1) A browser, C, connects to a server, S, which claims to be some enterprise (Macy’s) • (2) S sends C a copy of its certificate -- in the clear

47. SSL Protocol • (3) C verifies that the certificate is valid using CA’s public key (stored in its browser) • C now knows S’s public key • Generates a (symmetric) session key, KSess , and sends it to S encrypted with S’s public key • C generates KSess since it can send an encrypted message to S, but not the other way around • The session now continues using KSess

48. Why SSL Works • C knows it has established a session key with the enterprise that S claimed to be • C made up the session key and sent it to S using the public key found in its certificate • The certificate guarantees that the public key corresponds to the enterprise named in the certificate

49. Purchasing using SSL • If C needs to be authenticated to S, it sends its password, encrypted with the session key • In some applications, C might have a certificate • In many purchasing applications, such authentication is not required • C sends its credit card number, encrypted with the session key • S learns C’s credit card number (a possibly undesirable side effect)

50. Secure Electronic Transactions Protocol -- SET • A transaction-oriented protocol • Developed by Visa and MasterCard • The merchant, M, does not learn the customer’s credit card number • In addition to C and M, there is a trusted third party, G, the payment gateway • Uses a linear commit