Electronic Payments. EITN40 - Advanced Web Security

Transcription

1 Electronic Payments EITN40 - Advanced Web Security 1

2 Card transactions Card-Present Smart Cards Card-Not-Present SET 3D Secure Untraceable E-Cash Micropayments Payword Electronic Lottery Tickets Peppercoin Bitcoin EITN40 - Advanced Web Security 2

3 Credit card or Debit card Involved parties Cardholder Merchant Issuer The Cardholder s Bank Acquirer The Merchant s Bank The Network VisaNet for Visa BankNet for MasterCard For American Express, Discover Card, JCB and Diner s club, the issuer and the acquirer are the same We do not consider them here Issuer Cardholder VisaNet/ BankNet Merchant Acquirer EITN40 - Advanced Web Security 3

4 1. Cardholder presents card to Merchant 2. Merchant requests authorization from Acquirer 3. Authorization forwarded to Network Phase 1, Authorization 4. Network knows where to find Issuer and asks for authorization 5. Issuer sends authorization response to Network 6. Network forwards it to the Acquirer 7. Acquirer forwards it to the Merchant Issuer VisaNet/ BankNet 3 Acquirer Cardholder Merchant EITN40 - Advanced Web Security 4

5 1. Merchant sends approved authorizations to Acquirer (sent in a batch) 2. Acquirer credits Merchant s account and takes a fee 3. Bank sends authorization to the Network Phase 2, Clearing and Settlement 4. Network requests money from the issuer 5. Issuer sends money to Network 6. Network sends money to Bank and takes a fee 7. Cardholder pays invoice or has money directly debited her account with Issuer Cardholder s account 7 Issuer c VisaNet/ BankNet b 3 Acquirer 2 a Merchant s account 7 Cardholder 1 Merchant Fees: a: Mechant discout (All) b: Assessment (small) c: Interchange (large) Acquirer keeps a-b-c (small) EITN40 - Advanced Web Security 5

6 Transactions can be one of Card-Present Transaction (CP) Card-Not-Present Transaction (CNP) Two important security checks The card must not be a copy of a real card The cardholder must be the true owner EITN40 - Advanced Web Security 6

7 Cardholder, Card and Merchant are at the same place when purchase is made Physical stores, Hotels Card reader is typically used, magnetic stripe cards started to appear in the 60 s Magnetic stripe cards, security features Check that card is valid Physical protection, e.g., hologram Card verification value (CVV1) code on the magnetic stripe (verified by issuer) Check cardholder Signature Possible: PIN stored with issuer, provides two-factor authentication Reading the magnetic stripe + knowing PIN is often enough to use card Skimming 1958 EITN40 - Advanced Web Security 7

8 EMV (Europay, MasterCard, Visa) Since Jan 1, 2005: Merchants are responsible for fraud when EMV cards are not used (if they could have been used) Important features Difficult to copy Tamper resistant Secure storage Cryptographical computations Based on standards Common Criteria evaluation Still, cheap EITN40 - Advanced Web Security 8

9 Checking that card is valid Card includes public key, certificate of issuer and signed card data Network is root certificate Card can also have unique key pair for each card Card authentication Terminal verifies card data and digital signature Online or Offline Checking cardholder Cardholder verification PIN can be checked either online or offline Signature is also possible What should be done is based on policies set by issuer and acquirer EITN40 - Advanced Web Security 9

10 Mail/Telephone/Fax/Internet Important to verify that Alice is in possession of card and that she is the owner of the card Typically two ways Verify billing address Alice must present the billing address of the card Address Verification System (AVS) Expiry date CVV2/CVC2/CID this also checks that card is valid Verification code is not technically needed but typically gives Merchant less problem in case of chargebacks Merchant s are typically liable for CNP transactions CVV2 EITN40 - Advanced Web Security 10

11 Often, e-commerce is defined as purchasing over Internet Card-not-present transaction over Internet SSL/TLS makes a very good starting point. High security Free to use Built into web browsers However, Merchant will have access to card information Secure Electronic Transaction (SET) was first published in 1997 This technology separates internet payments from MOTO Internet EITN40 - Advanced Web Security 11

12 Initiated by Visa and MasterCard with several large companies involved Protocol is now dead, but it provides several important lessons Aims to separate payment information and order information Card number not given to Merchant PI = Payment information Only given to Issuer OI = Order information Only given to Merchant Three parties involved Cardholder Merchant Payment gateway EITN40 - Advanced Web Security 12

13 Concept introduced in SET PI H PIMD Customer private key H Sign Dual signature OI H OIMD Let Merchant see OI and PIMD PI and OI linked together, but Merchant cannot see PI EITN40 - Advanced Web Security 13

14 Divided into purchase request payment authorization payment capture (just finishing the actual payment, we skip this part) All parties have public/private key pair and a corresponding certificate 1. Initiate Request 2. Initiate Response 3. Purchase Request 6. PurchaseResponse 4. Authorization Request 5. Authorization Response 7. Capture Request 5. Capture Response EITN40 - Advanced Web Security 14

15 Initiate Request Cardholder requests Merchant and Payment Gateway s certificates Initiate Response Merchant returns certificates and a signed Transaction ID Cardholder prepares OI and PI and constructs the dual signature Transaction ID included in both PI is symmetrically encrypted, encryption key is encrypted with Gateway s public key Purchase Request Cardholder sends own certificate, dual signature, encrypted PI, PI digest and OI Merchant checks signature If all is ok, Purchase Response is sent 1. Initiate Request 2. Initiate Response 3. Purchase Request 6. PurchaseResponse EITN40 - Advanced Web Security 15

16 Authorization Request Merchant sends Encrypted PI, dual signature, OI digest, Signed Transaction ID, Cardholder s and Merchant s Certificates Everything is signed by merchant and symmetrically encrypted, encryption key is encrypted with Gateway s public key Gateway verifies certificates and signatures and checks that transaction ID is same in PI and message. Gateway authorizes payment with issuing bank Authorization Response Response that purchase is authorized is returned to merchant, symmetrically encrypted, encryption key is encrypted with Merchants public key Capture request and response Payment is finalized 1. Initiate Request 2. Initiate Response 3. Purchase Request 6. PurchaseResponse 4. Authorization Request 5. Authorization Response 7. Capture Request 8. Capture Response EITN40 - Advanced Web Security 16

17 Technically great Confidentiality, authentication, integrity and non-repudiation on message level Merchant does not get the card details Some reasons for failure: Cardholder needed to install special software on PC Possibly creating interoperability problems Problem with malware Not very simple for users with limited computer skills PKI infrastructure needed Complex scheme with large deployment costs EITN40 - Advanced Web Security 17

18 New attempt to secure online purchases Developed by Visa and adopted also by MasterCard Very different from SET Cardholder is authenticated with issuer Verify that she owns the card The rest is as usual Three Domains (the 3D in the name) Issuer domain The cardholder and the issuing bank Acquirer domain The Merchant and the acquiring bank Interoperability domain Domain connecting issuing and acquiring domain (card network and Internet) EITN40 - Advanced Web Security 18

19 Issuer implements an access control server and enrolls cardholder Merchant implements an MPI (or pays for a service that implements one) Card network has a Directory Server (DS) Can map card issuer Issuer/ACS DS Merchant/MPI Two phases when purchase is made Verify Enrollment Cardholder Authentication EITN40 - Advanced Web Security 19

20 1. Card details 2. Verify Enrollment Request (VEReq) Is card enrolled? 3. Is card enrolled? 4. Yes/No 5. Verify Enrollment Response (VERes) Yes/No If yes, URL to issuer s authentication is included in VERes Issuer Domain Interoperability Domain Acquirer Domain 1 2 Merchant/MPI 5 3 DS 4 Issuer/ACS EITN40 - Advanced Web Security 20

21 1. Payer Authentication Request (PAReq) - Open URL to authentication webpage in an iframe, including cardholder chosen hello message 2. Cardholder is authenticated 3. Payer Authentication Response (PARes) to MPI via web browser 1. Status result included in response 2. MPI can determine if authentication was successful and allow the purchase 4. Issuer sends result to history server so that disputes can be handled 5. Merchant can proceed by making authorization request, using the status result Issuer Domain Interoperability Domain 1 3 Acquirer Domain Merchant/MPI DS 5 4 Issuer/ACS History Server Acquirer EITN40 - Advanced Web Security 21

22 Merchant gets advantages Liability shifts from Merchant to Issuer/cardholder Protected from chargebacks guarantueed payment Issuer gets advantages Merchants are willing to accept the cards, so they are used more Easier to use than SET for cardholders Just get a password with your bank Still, some may find it annoying Liability possibly shifted to cardholder EITN40 - Advanced Web Security 22

23 Pop-up previously used instead of IFrame Difficult to know if you are really connected to Bank when password is given Activation during shopping - People are not focused on selecting secure passwords with bank when they are in the middle of a purchase Recommended reading: Murdoch and Anderson - Verified by Visa and MasterCard SecureCode: or, How Not to Design Authentication, 2010 EITN40 - Advanced Web Security 23

24 When using credit and debit cards, the issuing bank can track your shopping behaviour With cash, you are anonymous Well...there is a serial number on bills...but it is quite useless for tracking Using anonymous electronic coins is one alternative Two main problems that need to be solved Creation must be controlled by bank Should not be possible to double spend a coin Example: Principles behind DigiCash EITN40 - Advanced Web Security 24

25 Merchant Bank 4. Electronic coins Alice must not be able to create her own coins! Alice 1. Alice asks bank for electronic coins 2. Issue electronic coins 3. Send electronic coins to merchant upon buying something 4. Merchant deposits the electronic coins into his own account EITN40 - Advanced Web Security 25

26 Merchant Bank 4. Signed Electronic coins Alice Alice must not be able to create her own coins! Use digital signature Still, bank can trace coin back to Alice 1. Alice asks bank for electronic coins 2. Issue electronic coins 3. Send electronic coins to merchant upon buying something 4. Merchant deposits the electronic coins into his own account EITN40 - Advanced Web Security 26

27 Idea is to let someone sign a document without seeing the document....or digitally sign a number without seeing the number Recall RSA: Public modulus n and exponent e Private exponent d. Sign the value x by using hash function h() and computing Verify by computing...and check that EITN40 - Advanced Web Security 27

28 Multiplicative property of (plain) RSA: This is why we sign a hash (known redundancy)...but it can also be used to blind the signature 1. Pick random r 2. Let signer sign 3. Signature is 4. Multiply signature by inverse of r to get a signature on x EITN40 - Advanced Web Security 28

29 Alice generates two random numbers x is a coin r is a blinding value Let e = 3 Alice computes Bank and sends B to the bank Bank signs B and returns the signature B B d to Alice Withdrawal is complete! x is a coin signed by bank, but bank has not seen x, or h(x) Alice EITN40 - Advanced Web Security 29

30 Bank 3. Ask if x has been spent 4. Signed Electronic coins Merchant 2. Verify signature Alice computes When buying something 1. Alice sends to Merchant 2. Merchant verifies the signature using the Bank s public key (e = 3) 3. Merchant checks with bank that x has not been spent before 4. Merchant deposits x by sending to the bank Alice Bank knows it is a valid coin but it has not seen x before so it can not be traced to a specific person 1. Signed Electronic coins EITN40 - Advanced Web Security 30

31 Problems Step 3 is used to prevent double spending, but it is not very practical If Alice double spends, she is still anonymous and can not be punished The following two features will be added 1. Merchant does not have to contact the bank for every transaction in order to check double spending 2. If and only if Alice double spends, she will be identified by the bank Note that by solving the second problem, the first is implicitly solved EITN40 - Advanced Web Security 31

32 Alice chooses 2k quadruples of random numbers Let and compute These values are sent to the bank Bank uses cut-and-choose to verify that a random half of the B i correctly identifies Alice Rest are used to compute the blind signature, which is regarded as the coin. EITN40 - Advanced Web Security 32

33 1. Alice sends all B i to bank 2. Bank selects k indices randomly and sends these to Alice 3. Alice reveals how B i was computed for these indices. Sends 4. Bank checks that ID is ok for all EITN40 - Advanced Web Security 33

34 For all other indices, Bank computes and sends this value to Alice Alice extracts S which is the coin EITN40 - Advanced Web Security 34

35 Alice sends the signature to Merchant Merchant generates random sends to Alice Alice returns and Now, Merchant can verify the signature since but not identify Alice Merchant can at any time send coin, z and Alice s responses to Bank If Alice double spends, Bank can identify Alice since the new merchant will use another z EITN40 - Advanced Web Security 35

36 Alice can use a signature together with ID so she can not be framed by bank Zero-knowledge proofs can be used instead of cut-andchoose Alice proves that her ID is inside B i without revealing half of the B i values See evoting lecture for more info on this Minimize computations, storage space, amount of communication needed etc... EITN40 - Advanced Web Security 36

37 Card fees and interchange fees are sometimes large compared to purchase Buying/selling cheap items not (economically) possible Micropayment: payment where transaction fee is a substantial part of total transaction To merchant Fees Macropayment: Payment where transaction fee is a small part of total transaction To merchant Fees EITN40 - Advanced Web Security 37

38 All micropayment schemes are based on aggregation Transform several micropayments to one macropayment Three types of aggregation Session-level aggregation Universal aggregation Aggregation by intermediation EITN40 - Advanced Web Security 38

39 Alice makes several purchases from the same merchant Someone keeps track of total amount After some period of time all purchases are collected into one macropayment Phone bill is one example but users can not control how much money the company can charge We have to trust their system so they do not charge more than what we have authorized We can easily fix this (at least mathematically) micropayment Alice micropayment micropayment micropayment micropayment Merchant macropayment Bank EITN40 - Advanced Web Security 39

40 Alice (A) has a certificate signed by the Bank (B) When making purchases from a new Merchant, Alice computes a hash chain Alice commits to w 0 by sending to Merchant (M) Alice Merchant Merchant checks that Alice has account with Bank EITN40 - Advanced Web Security 40

41 When Alice buys something that costs 1 unit she sends to Merchant i is incremented for each micropayment Alice Merchant If something costs m units, i is incremented by m Merchant can always check that it is a valid payment But he can never compute EITN40 - Advanced Web Security 41

42 Commitment S and w t is sent to the bank when t is large enough Merchant Bank Bank verifies w t before crediting the Merchant s account and debiting Alice s account EITN40 - Advanced Web Security 42

43 Session-level aggregation only aggregates between one costumer and one merchant Universal aggregation is instead many-to-many micropayments macropayments Bank Alices Merchants EITN40 - Advanced Web Security 43

44 Probabilistic payments Micropayment is μ SEK Macropayment is γ SEK A macropayment is paid with probability s = μ / γ SEK First time Alice buys from Merchant, Merchant creates his own hash chain And sends m 0 to Alice, which is included in her commitment If then Alice pays γ SEK EITN40 - Advanced Web Security 44

45 Alice Merchant Alice can verify that payment must be made Bank EITN40 - Advanced Web Security 45

46 Problems Interaction Psychological problem for Alice She sometimes pays more than she has spent. Improvement: Peppercoin Alice never pays more than she has actually spent and merchant always gets γ SEK Bank takes the psychological problem Less, or no, interaction EITN40 - Advanced Web Security 46

47 Basic principles T is info about purchase S is a number that is incrementing for each micropayment F is a function mapping a binary string to a number between 0 and 1 Alice sends to Merchant Alice Macropayment is made if Merchant EITN40 - Advanced Web Security 47

48 Basic principles If macropayment should be made, the data is sent to the bank Merchant Bank Bank keeps record of highest S that has been paid, Bank verifies signatures Credits merchant s account with γ SEK Debits Alice s account with updated as Need to make sure that S is not reused with different merchants EITN40 - Advanced Web Security 48

49 A third party is placed inbetween users and merchants to keep track of all micropayments When a user has paid enough, he/she will be charged by the intermediary Or he/she will pre-pay a certain number of transactions When merchant has received enough, he will get transaction from intermediary EITN40 - Advanced Web Security 49

50 A currency of its own Money is printed within the system No issuer Completely decentralized Peer-to-peer No banks involved Idea: Use asymmetric cryptography Money is owned by public key Anonymous Can be represented by QR-code Transferred to a new public key by signing a transaction with the corresponding private key Simple enough, but what about double spending? EITN40 - Advanced Web Security 50

51 Transactions tied together New public key can be used for each transaction Not possible to track history Each user has many addresses Broadcast transaction to everyone Transaction From: To: Signature: EITN40 - Advanced Web Security 51

52 1 hash: 26a6230f29715cfbb19b be3195b837f667b2c6a46ac6adee 2 in: 3 prev_out: 4 hash: 3e5969d6314cdf5b8...edad50c1eaea3ae7bc94cb44479c82 5 n: 1 6 scriptsig: cd cef0b2360f51aa43ca2b e744fd5b041b...a6b888082c839368e510134a3251ab 8 out: 9 value: , 10 scriptpubkey: fa532de64071fb72198d17fc4ebdc0210d value: , 13 scriptpubkey: 07c017250f85b2590a31730c fd83dcc62 Hash of transaction, identifies this transaction Inputs Refer to previous output Public key and signature to authorize use of that output Outputs Send some money to one public key Send some money to another public key EITN40 - Advanced Web Security 52

53 In1 Out1 Out2 Out3 In1 Out1 Out2 In1 In2 Out1 In1 Out1 Out2 In1 In2 Out1 In1 Out1 In1 Out1 In1 In2 Out1 Out2 unused EITN40 - Advanced Web Security 53

54 Still need to fix double spending...and this is where it gets interesting Proof-of-work: It requires a large amount of work in order to make a transaction valid Transactions are broadcasted publicly Received transactions are combined into one block Block is validated by adding it to a block chain Block x Block x+1 Block x+2 Transaction i Transaction i+1 Transaction i+2 Transaction j Transaction j+1 Transaction j+2 Transaction k Transaction k+1 Transaction k+2 EITN40 - Advanced Web Security 54

55 1 hash: f4f1...3a8a001c3307e0e6cbea474798a223e9e50, 2 prev_block: a4d5d ceb9f8f52f86aeeef8e3b52464, 3 mrkl_root: 18353cf8f8f4bfa2ecff...923b40871a016d1793f1a946a1201, 4 nonce: , 5 tx: Blocks linked together by referring to previous block Hash value must be smaller than some number Updated continuously so that it always takes about 10 minutes for the world to compute a valid block Nonce used to give variations in hash EITN40 - Advanced Web Security 55

56 A transaction is valid when it is in a valid block Well not necessarily The block chain can, and will, fork Block Block Block Block Block Block The longest fork is by definition valid So people will stop working on short ones When a transaction is buried under enough blocks, it is safe to assume that it will not change Around 5 or 6 should be enough (about 1 hour) EITN40 - Advanced Web Security 56

57 Computers dedicated to creating valid blocks are called miners Why would anyone work on creating a valid block? The creator puts a transaction of 25 BTC to himself as first transaction in a block! New money is entered into the system Transaction fees are optional Difference between input and output in a transaction If input sums to 30 BTC and output sums to 29 BTC there are 1 BTC left which the miner can send to himself Transaction will be included in a block faster if there is a transaction fee since miners have incentive to include it in the block EITN40 - Advanced Web Security 57

58 Changing past transactions will require that a new chain is computed which is longer than the one used Would make the new chain the real one Block Block Block Block Block Block Block Block Attacker require majority of total computing power EITN40 - Advanced Web Security 58

59 Reward will decrease over time Number of BTC will be around 21 million Gives deflation Very similar to pyramid game Early adopters will gain the most Private keys are sometimes lost This money can never be used The anonymity enables illegal use EITN40 - Advanced Web Security 59