WEBVTT 00:02.130 --> 00:03.070 Good morning. 00:03.990 --> 00:07.530 I'd like to welcome you to another session on algorithms for Internet 00:07.530 --> 00:08.130 applications. 00:08.570 --> 00:15.270 Oh, I should switch the monitor, the screen, the beamer. 00:17.390 --> 00:18.590 Data projector. 00:20.710 --> 00:27.610 Beamer, actually, is not an adequate word in English. 00:27.610 --> 00:33.950 Okay, so I would just like to start by giving you a short 00:33.950 --> 00:40.670 advertisement for our seminar that we are offering next term. 00:41.190 --> 00:45.210 Summer semester, we are offering a seminar on learning systems. 00:45.410 --> 00:49.130 Maybe you're interested in something like that. 00:49.890 --> 00:53.390 This course certainly has nothing to do with learning systems, 00:53.390 --> 00:57.710 although if you're looking through the Internet, you could actually 00:57.710 --> 01:02.010 use learning systems there for certain aspects, for search engines and 01:02.010 --> 01:03.870 so on, but you couldn't get into these topics. 01:04.710 --> 01:10.630 So this seminar is motivated by our research projects on organic 01:10.630 --> 01:16.210 computing, and the important part there is to have learning 01:16.210 --> 01:19.570 methodologies in these organic systems. 01:19.570 --> 01:32.110 So our seminar content in the summer will be, well, learning systems, 01:32.310 --> 01:33.150 all kinds of things. 01:33.270 --> 01:39.810 For example, technologies that are used in autonomous robots or here. 01:39.810 --> 01:47.410 This actually is a collection of faces and learning methodologies for 01:47.410 --> 01:49.330 recognizing faces. 01:49.790 --> 01:58.930 Or you want to control traffic, street lights, or maybe you want to 01:58.930 --> 02:01.130 control traffic on highways. 02:01.910 --> 02:04.050 So there are approaches to that. 02:04.050 --> 02:10.490 Or you want to play backgammon, for example, with a specific method, 02:10.730 --> 02:14.050 type of difference learning, which is explained with respect to such a 02:14.050 --> 02:14.290 game. 02:14.670 --> 02:19.310 Or you want to classify email into spam and not spam and use a 02:19.310 --> 02:20.430 learning system for that. 02:20.990 --> 02:23.910 So different algorithms are used for these things. 02:24.750 --> 02:31.730 And the seminar will focus on presenting not just methods, but also 02:31.730 --> 02:33.870 presenting applications of these methods. 02:33.870 --> 02:38.070 So if you're interested in that, just come to the preparatory meeting 02:38.070 --> 02:44.390 on, that's in two weeks from now, 15th of February, 2 p.m. 02:44.570 --> 02:47.930 in our room 56 in our building. 02:48.550 --> 02:51.450 If you want to see more about that, just look at the website. 02:52.290 --> 02:57.030 And you can pre-register by sending an email to my assistant, Dino 02:57.030 --> 02:57.390 Penke. 02:58.240 --> 03:07.670 So, again, the main motivation is that we want to see how nature is 03:07.670 --> 03:13.210 learning, how we can copy these methods into algorithms in 03:13.210 --> 03:13.830 informatics. 03:14.810 --> 03:19.110 And what we see in nature is that there are organisms capable of 03:19.110 --> 03:23.950 changing their behavior by processing external influence, by reacting 03:23.950 --> 03:26.010 appropriately to external influences. 03:26.590 --> 03:30.070 And we want to see how that works in informatics. 03:30.590 --> 03:33.350 Okay, that's the commercial on our seminar. 03:34.370 --> 03:39.790 And another point is that we're also looking for a teaching assistant, 03:40.050 --> 03:44.430 not for a teaching assistant, a research assistant, in one of our 03:44.430 --> 03:46.810 projects on organic computing. 03:47.710 --> 03:53.310 We do something on traffic control, and we're currently looking for 03:53.310 --> 03:57.670 interested students to work together with us in these projects. 03:59.050 --> 04:07.890 Okay, that's the short commercial on the seminar. 04:08.730 --> 04:15.430 And now I want to get to our course contents. 04:15.430 --> 04:21.430 Last time we finally finished the chapter on... 04:22.410 --> 04:25.270 briefly go to that slide... 04:25.270 --> 04:28.890 we ended our chapter on cryptography. 04:29.490 --> 04:37.990 I showed you the final protocol there, which is essentially this 04:37.990 --> 04:46.190 protocol, where we combine all the different parts of our... 04:46.190 --> 04:50.410 all the different methods that we got to know in this chapter. 04:51.290 --> 04:54.790 We used there many different things. 04:56.730 --> 05:04.090 We used signatures, so we used message digest, this function F. 05:04.090 --> 05:11.010 We used asymmetric methods by creating a different signature, and we 05:11.010 --> 05:15.410 used symmetric methods for encrypting message. 05:16.130 --> 05:23.310 We used, here again, the certification of keys, public keys, in order 05:23.310 --> 05:28.290 to be sure that we actually have the right or the correct public key 05:28.290 --> 05:32.930 of the recipient of the message to encrypt the session key. 05:33.730 --> 05:42.290 And the recipient could then decode or decipher, decrypt the message 05:42.290 --> 05:46.770 by retrieving the key, and could check the validity of the contents by 05:46.770 --> 05:47.930 using the signature. 05:48.210 --> 05:52.010 So that was a combination of all these different things. 05:52.190 --> 05:57.250 And I mentioned just one possible attack, this birthday attack on such 05:57.250 --> 05:59.710 a document, which is very unlikely to succeed. 06:00.130 --> 06:04.170 But if you want to really get complete security, then you have to do a 06:04.170 --> 06:04.470 bit more. 06:05.150 --> 06:08.770 And one other word, certainly, I just said complete security. 06:09.710 --> 06:18.870 There's always possibility that somebody enters this system and, well, 06:18.950 --> 06:21.030 somehow changes things. 06:21.030 --> 06:26.910 So you cannot guarantee complete security, but what you always should 06:26.910 --> 06:30.890 do is apply all the methods that are available in order to make the 06:30.890 --> 06:37.490 probability of some manipulation just very, very small. 06:37.930 --> 06:42.830 And I think we looked at possible methods that could be used there. 06:42.830 --> 06:48.550 Certainly this all depends on the, for example, the secrecy of the 06:48.550 --> 06:49.710 secret key. 06:50.310 --> 06:56.010 If a person just has the secret key in a place that is available to 06:56.010 --> 06:58.750 other persons, then there is no security anymore. 06:59.570 --> 07:02.790 Okay, that was our chapter on cryptography. 07:04.450 --> 07:15.650 And then we come now to our next chapter, which is on electronic 07:15.650 --> 07:16.890 payment systems. 07:17.530 --> 07:21.750 Electronic payment systems actually is an area where we apply 07:21.750 --> 07:24.630 cryptographic methods, as you will see. 07:25.070 --> 07:28.830 We will start by just looking at what electronic payment systems are. 07:28.830 --> 07:33.630 This certainly is an interesting application in the Internet. 07:33.890 --> 07:41.390 We want to buy certain things, perform business over the Internet with 07:41.390 --> 07:42.730 the World Wide Web for that. 07:43.090 --> 07:46.210 We have to look at how we can actually pay for things that are 07:46.210 --> 07:46.930 available. 07:47.570 --> 07:52.910 So, there are different systems around. 07:54.130 --> 08:01.190 This is a list of systems that are mentioned with respect to secure 08:01.190 --> 08:02.110 payment methods. 08:02.930 --> 08:08.150 The first thing would be to just use secure channels for exchanging 08:08.150 --> 08:11.930 information on payment by using SSL or TLS. 08:11.930 --> 08:17.050 I will briefly mention that, but this is just to have a secure 08:17.050 --> 08:17.610 channel. 08:17.990 --> 08:22.610 So, you have the application here, then you have your channel between 08:22.610 --> 08:30.950 the different ports of the two computers, two hosts. 08:30.950 --> 08:37.110 But the only thing that is secure here in SSL or TLS is the 08:37.110 --> 08:42.130 connection, this logical line between the two applications will be 08:42.130 --> 08:50.210 secure, but not the systems that are above the ports of TCP. 08:51.570 --> 08:54.070 Okay, then there is a payment protocol, SEP. 08:54.310 --> 08:56.010 I will show you how that works. 08:56.010 --> 08:59.670 This is secure electronic transactions, which actually provides secure 08:59.670 --> 09:02.070 methods in the application. 09:02.310 --> 09:04.690 So, this is much more than just SSL or TLS. 09:05.510 --> 09:07.630 And there are certain payment server systems. 09:07.750 --> 09:09.270 I will present you one of those. 09:09.790 --> 09:15.590 I will also present to you an idea of how to create electronic money, 09:16.370 --> 09:22.470 just units of money that can be transferred over the Internet. 09:23.230 --> 09:28.090 And I will briefly also make a few remarks on smart cards that could 09:28.090 --> 09:31.550 also be used for paying small amounts of money. 09:33.270 --> 09:37.690 Let's start by looking at just the concepts of payment systems. 09:38.270 --> 09:42.090 So, there are different types of payment systems around. 09:42.550 --> 09:46.150 Two-party, three-party, open-loop, stored value systems. 09:46.150 --> 09:49.110 And these are all based on prepayment. 09:50.430 --> 09:58.750 When you have your coins in your wallet, this is prepayment. 09:58.810 --> 10:04.190 Because in order to get money from the bank, to withdraw money from 10:04.190 --> 10:09.010 the bank by just getting coins in your hand, you have to withdraw a 10:09.010 --> 10:11.190 certain value from your account. 10:11.190 --> 10:18.350 And so then you have these metal things that are supposed to bear some 10:18.350 --> 10:18.830 value. 10:20.650 --> 10:23.370 So this is all based on prepayment. 10:23.970 --> 10:27.950 And there are other payment methods around based on credit cards where 10:27.950 --> 10:34.410 you actually pay for something, but the values are transferred at a 10:34.410 --> 10:35.010 later time. 10:35.610 --> 10:39.390 So let's first look at these prepayment-based methods. 10:39.390 --> 10:46.990 The first level is that the client may only buy at the emitter of 10:46.990 --> 10:48.950 these stored values. 10:49.310 --> 10:53.250 So here is the simple setting that you have the university and its 10:53.250 --> 11:00.930 students, and you want to get some, or you want to pay in electronic 11:00.930 --> 11:01.550 form. 11:01.910 --> 11:06.790 So you have to provide some money to the university, and then you get 11:06.790 --> 11:12.710 some stored value back, for example, on your free card or chip key or 11:12.710 --> 11:13.590 something like that. 11:14.390 --> 11:20.130 You get its stored value, and you can use this stored value to get 11:20.130 --> 11:20.810 some service. 11:20.970 --> 11:24.750 So you just present this stored value again to the university or some 11:24.750 --> 11:29.710 service at the university, get these services, copier, printer, meals, 11:29.850 --> 11:40.050 or whatever, and so this way you can use this two-party stored value 11:40.050 --> 11:40.550 system. 11:40.670 --> 11:43.550 The first level of an electronic payment system where you just have 11:43.550 --> 11:49.890 students and university, and the students can use these stored values 11:49.890 --> 11:56.190 only with the party or with the emitter of those stored values. 11:56.910 --> 12:02.110 The second level would be that you can use these stored values also at 12:02.110 --> 12:03.050 different locations. 12:03.510 --> 12:09.630 That means you can go to other places, you present your money to the 12:09.630 --> 12:17.050 university, it gets the stored value back, and then you can use the 12:17.050 --> 12:21.350 stored value to go to some shop and pay there. 12:21.350 --> 12:27.610 And then another party comes into this game here, the shops, to get 12:27.610 --> 12:34.390 some services, and the shop certainly will provide you the service, 12:34.870 --> 12:39.690 but certainly has to get the value that is represented in this stored 12:39.690 --> 12:44.190 value that is handed over to the shop in some form. 12:44.310 --> 12:47.790 So the shop will present the stored value to the emitter, to the 12:47.790 --> 12:55.890 university in this case, and then the stored value is re-transferred 12:55.890 --> 13:01.410 into money, and the shop gets, or the merchant gets, the money that is 13:01.410 --> 13:06.710 equivalent to the service that it provided. 13:07.310 --> 13:12.990 So, in this case, there is now another shop, or another party in 13:12.990 --> 13:17.610 there, another participant, who will accept the stored value, and 13:17.610 --> 13:23.070 certainly it is a question, what is the actual sequence of operations 13:23.070 --> 13:23.610 here? 13:24.150 --> 13:29.650 Do you get the service before the stored value is actually transferred 13:29.650 --> 13:30.370 into money? 13:33.790 --> 13:41.130 And can the... will the merchant trust the stored value? 13:41.190 --> 13:43.110 Is it possible to just use the stored value? 13:43.110 --> 13:46.550 And maybe the merchant could use on this stored value. 13:46.690 --> 13:48.470 This is not included in this setting. 13:49.190 --> 13:56.190 The merchant can only go to the university, to the emitter, and have 13:56.190 --> 13:58.810 the stored value re-transformed into real money. 14:01.350 --> 14:04.890 Now, certainly for a real world example, you could replace here 14:04.890 --> 14:06.990 student, customer, university, bank. 14:07.110 --> 14:11.530 That's obvious, but it works also in this university setting. 14:11.530 --> 14:16.270 The third level is the open loop system, where you would have 14:16.270 --> 14:19.210 electronic money that can circulate freely through several 14:19.210 --> 14:19.990 transactions. 14:20.730 --> 14:24.930 You have the university emitting the stored value, or the bank, 14:25.370 --> 14:25.750 whatever. 14:26.330 --> 14:31.490 Then the students can go to some shops and present their stored value, 14:31.910 --> 14:35.010 get some goods for that, or services. 14:35.740 --> 14:41.090 And the stored values may be used, certainly to be re-transformed into 14:41.090 --> 14:49.270 money, but may also be used by other... 14:49.270 --> 14:56.070 or at other places to get other goods for these stored values. 14:56.070 --> 15:00.930 So this would be the function that we know from cash, that we use to 15:00.930 --> 15:03.630 just buy at any place. 15:03.990 --> 15:08.670 And certainly we can deposit the cash to the bank, and then the value 15:08.670 --> 15:10.050 is deposited to our account. 15:10.510 --> 15:15.010 That would be the re-transformation of cash into money. 15:16.050 --> 15:16.710 Okay. 15:17.790 --> 15:23.250 And so this, here, there may be other students who maybe work at the 15:23.250 --> 15:25.630 shop, and get a stored value back. 15:26.410 --> 15:35.390 And they might also provide, or get services from others, and again 15:35.390 --> 15:37.730 provide stored values to students. 15:37.930 --> 15:40.790 So here we have a system that is much more complex. 15:40.790 --> 15:44.030 The stored values can circulate freely in the system. 15:44.610 --> 15:50.230 And certainly this depends very much on one important point. 15:51.050 --> 15:59.630 Whenever such a shop here, or student that has some participant in the 15:59.630 --> 16:01.890 system, gets a stored value. 16:02.030 --> 16:06.850 So here you get a stored value from a shop there, also from another 16:06.850 --> 16:07.570 merchant. 16:09.630 --> 16:15.930 How do you know that what you get there actually has the value that is 16:15.930 --> 16:16.610 written on it? 16:17.510 --> 16:18.630 This is not obvious. 16:19.110 --> 16:24.470 If we know it from cash, obviously if you have a one euro coin, that's 16:24.470 --> 16:25.130 worth one euro. 16:25.990 --> 16:30.850 We know it because we are confident that when we present that to the 16:30.850 --> 16:33.790 bank, we will deposit one euro to our account. 16:34.670 --> 16:40.270 But if you just have a piece of money in your computer, maybe you can 16:40.270 --> 16:46.470 easily copy these entities in your computer that represent cash. 16:47.130 --> 16:53.290 Now you have to make sure that this copying of stored values is not 16:53.290 --> 16:55.330 done without being noticed. 16:56.190 --> 17:02.330 So this is one of the major problems in these attempts to get real 17:02.330 --> 17:03.450 electronic money. 17:04.190 --> 17:10.670 To get some confidence in the validity of the electronic coins that 17:10.670 --> 17:12.910 you use for paying at some place. 17:15.330 --> 17:19.630 Then there are lots of evaluation criteria that you could use for 17:19.630 --> 17:23.050 evaluating these electronic payment systems. 17:23.050 --> 17:28.150 One of the first things would be system security, reliability, and 17:28.150 --> 17:31.530 safety of this system. 17:32.830 --> 17:36.730 If you want to pay something, this has to be reliable and safe. 17:36.950 --> 17:38.950 Nobody should be able to interfere with that. 17:38.950 --> 17:43.910 Then there may be some transaction costs if you have some, if you use 17:43.910 --> 17:48.650 some services for transforming money into, what we see as stored 17:48.650 --> 17:50.090 values, into real money. 17:50.770 --> 17:56.070 This will be some, for the use of certain computer power, maybe 17:56.070 --> 18:00.050 charge, maybe may result in some transaction costs. 18:00.770 --> 18:03.490 Then an important point is the traceability. 18:04.830 --> 18:11.790 If you use your cash to pay somewhere, nobody will know that you 18:11.790 --> 18:15.290 actually have used this cash. 18:15.510 --> 18:20.190 You cannot, there's no connection of a person with a coin that is 18:20.190 --> 18:20.570 used. 18:21.070 --> 18:24.810 There's no connection of a transaction with a coin. 18:26.090 --> 18:30.310 So, usually we have an anonymity with the use of cash. 18:31.110 --> 18:34.270 In electronic transactions, for example, if you use a credit card, you 18:34.270 --> 18:39.530 get a balance sheet at the end of the month, and you have completely 18:39.530 --> 18:44.390 listed all the transactions that you performed with your credit card. 18:44.470 --> 18:46.590 So there's a complete record of what you have done. 18:46.990 --> 18:52.130 The credit card company can simply trace your movements, your actions. 18:53.490 --> 18:58.550 And in electronic payment systems, one should try to get a certain 18:58.550 --> 18:59.460 level of anonymity. 18:59.890 --> 19:05.970 At least this is a criteria for evaluating these payment systems. 19:06.430 --> 19:10.790 Online checking requirements, somebody might, or it might be necessary 19:10.790 --> 19:13.070 to check the validity of a stored value. 19:13.830 --> 19:17.690 Acceptability, where can we actually provide these stored values? 19:17.690 --> 19:22.530 Is it possible to transfer amounts from one person to another? 19:23.250 --> 19:27.910 Is it possible to divide the amounts that you have into arbitrary 19:27.910 --> 19:28.910 units? 19:30.190 --> 19:34.090 And we will go deeper into these points. 19:34.790 --> 19:40.830 So, system security means we have to protect our communication 19:40.830 --> 19:45.390 channels, while we know that the isolation of the transmission 19:45.390 --> 19:48.930 infrastructure is a difficult thing. 19:49.310 --> 19:52.950 Although the banks have their own communication network, or at least 19:52.950 --> 19:57.930 had it for some time, for the chronic fund transfer, this is not 19:57.930 --> 20:01.810 sufficient, and we know that we have to use cryptographic protocols 20:01.810 --> 20:04.990 for secure transmission and communication, and for checking the 20:04.990 --> 20:09.030 integrity of information that is sent over these channels. 20:09.030 --> 20:15.890 So, then you could use authentication and identity check, by using PIN 20:15.890 --> 20:19.150 numbers, which is one level of security. 20:19.310 --> 20:25.750 If you use an automatic teller machine to get your money, then you 20:25.750 --> 20:26.770 just use your PIN. 20:26.930 --> 20:32.450 We all know that that is not really secure for just a four-digit 20:32.450 --> 20:35.830 number, but we all live with these risks. 20:35.830 --> 20:40.050 There could be password, passphrase systems, as I explained, could be 20:40.050 --> 20:44.370 P2P, could use digital signatures, could use intelligent chip cards. 20:44.550 --> 20:53.050 So, there are several ways available, which will result in different 20:53.050 --> 20:55.910 levels of risk that you have to accept. 20:56.630 --> 21:00.370 Then you could use mechanisms for hardware protection by using smart 21:00.370 --> 21:11.150 cards, which provide a means of actually hiding your secret 21:11.150 --> 21:15.650 information, making the transactions more secure. 21:17.130 --> 21:22.390 Transaction costs, what type of costs could be created? 21:23.290 --> 21:27.750 So, certainly transaction costs will be essential for the 21:27.750 --> 21:29.610 acceptability of these systems. 21:29.610 --> 21:35.590 You would never use an electronic payment system if you get high 21:35.590 --> 21:41.590 transaction costs with that, because, well, you don't want to pay for 21:41.590 --> 21:42.810 using your money. 21:43.150 --> 21:45.910 So, it has to be economical and acceptable. 21:47.050 --> 21:50.970 So, what type of costs could be created? 21:51.850 --> 21:56.510 It will need some time to check, for example, the validity of your 21:56.510 --> 21:58.810 electronic coin that you present. 21:58.810 --> 22:03.070 Then there may be certain fees for credit card accounting. 22:03.310 --> 22:09.690 You know that the merchant has to pay something like 2-3%, 5% fee for 22:09.690 --> 22:14.370 accepting, or for processing payment over a credit card. 22:15.250 --> 22:19.490 There may be transmission costs using your telephone lines, or there 22:19.490 --> 22:24.310 may be computer access fees, or hardware costs, or costs of processing 22:24.310 --> 22:27.290 of all these things. 22:27.290 --> 22:31.910 So, one has to try to make these costs very small. 22:32.790 --> 22:36.390 And these transaction costs must be reasonable in relation to the 22:36.390 --> 22:37.230 transmitted value. 22:37.710 --> 22:42.650 One of the major problems is that sometimes you use services in the 22:42.650 --> 22:49.850 internet, which are not free, but you have to pay a small amount of 22:49.850 --> 22:50.090 money. 22:50.090 --> 22:53.610 For example, you want to access a certain service, maybe you are 22:53.610 --> 22:56.030 charged just a few cents. 22:57.930 --> 23:02.470 And the question is, well, you certainly would never use a complicated 23:02.470 --> 23:05.730 payment system just to pay a few cents. 23:05.950 --> 23:08.890 If the transaction costs are higher than the value that is 23:08.890 --> 23:10.230 transferred, it doesn't make sense. 23:10.230 --> 23:17.970 So, micropayments that are worth something below or smaller than one 23:17.970 --> 23:26.090 euro, may be just accumulated so that you only transfer the values if 23:26.090 --> 23:33.010 a certain value has accumulated, or you just have to do it in a way 23:33.010 --> 23:39.310 that is very cheap, doesn't reside in high transaction costs. 23:39.310 --> 23:45.530 So micropayments is an important topic, because if you want to make 23:45.530 --> 23:48.550 money in the internet, you certainly have to charge a customer a 23:48.550 --> 23:53.830 certain amount of money, and you certainly don't want to charge a 23:53.830 --> 23:57.950 customer with high amounts, so the fees for using the service should 23:57.950 --> 23:58.810 be smaller. 23:59.670 --> 24:07.050 But if these have to be paid, well, the costs must be reasonable. 24:09.470 --> 24:12.070 Accountability, traceability, I mentioned that already. 24:12.410 --> 24:18.810 Accountability means who has used the money, what has the money been 24:18.810 --> 24:26.450 used for, so did you buy a book, or a movie, or whatever, which goods 24:26.450 --> 24:29.530 or services have been purchased, you know that on your credit card 24:29.530 --> 24:32.990 statement everything is listed, although the credit card company 24:32.990 --> 24:36.450 actually doesn't need all this information, it just wants to get its 24:36.450 --> 24:43.030 money, and only you would like to check whether everything that you 24:43.030 --> 24:52.410 see on your bill has been purchased, that you actually performed at 24:52.410 --> 24:52.850 some time. 24:53.850 --> 24:58.570 And another point is that usually you see where the money has been 24:58.570 --> 25:04.510 used, so the credit card company could build a movement profile of its 25:04.510 --> 25:11.170 customers, could be easily done, and nevertheless we use our credit 25:11.170 --> 25:15.910 cards, and don't mind that these possibilities are actually there. 25:19.410 --> 25:28.390 So, the advantages of accountability would be that certainly you could 25:28.390 --> 25:32.730 build highly efficient marketing databases, this is something which 25:32.730 --> 25:36.010 certainly is an advantage for the credit card company, you could sell 25:36.010 --> 25:41.650 the information it has to certain companies who want to market their 25:41.650 --> 25:49.150 products, and, well, you could say, well, that's not really good for 25:49.150 --> 25:53.590 the customer, but why is it bad if you get personalized 25:53.590 --> 25:56.110 advertisements? 25:58.690 --> 26:03.610 It's not really that much of a problem, it's just sometimes seen to be 26:03.610 --> 26:04.830 an intrusion into privacy. 26:06.250 --> 26:11.110 Certainly this would allow tracing of criminal activities, this is the 26:11.110 --> 26:19.230 hope of many politicians that by having all these systems could trace 26:19.230 --> 26:22.630 criminals, we know that, for example, the MALT system that we have on 26:22.630 --> 26:27.810 the German highways now would provide lots of information that could 26:27.810 --> 26:31.730 be used to trace criminal activities, but so far it's not allowed to 26:31.730 --> 26:33.850 do that, at least that's the official version. 26:34.950 --> 26:40.630 Then there is higher security of fund transfer, definitely you can 26:40.630 --> 26:46.330 check whether everything that is on your bill is correct, and you can 26:46.330 --> 26:53.310 only check that if you get all the information on who, what, and where 26:53.310 --> 26:58.890 is the money, who has used the money, what did you buy with the money, 26:59.030 --> 27:01.910 and where did you buy it, you get all this information, you can check 27:01.910 --> 27:03.950 if everything is correct. 27:05.650 --> 27:12.690 The opposite thing, the disadvantages, the contra-arguments are that 27:12.690 --> 27:16.550 traceability could be seen as a penetration into privacy, which 27:16.550 --> 27:24.070 certainly is true, we don't want to be completely transparent, and 27:24.070 --> 27:29.370 certainly the databases of customer information hold the potential of 27:29.370 --> 27:34.110 being attacked, you could use this information for purposes that are 27:34.110 --> 27:41.630 not really friendly, so there are pros and cons, and one has to get 27:41.630 --> 27:48.550 some level of accountability, or one should maybe provide means of 27:48.550 --> 27:55.030 controlling the level of accountability that is provided by these 27:55.030 --> 27:55.470 systems. 27:55.470 --> 27:59.930 It should be controllable by the customers, and not by the providers 27:59.930 --> 28:01.330 of these services. 28:03.110 --> 28:06.830 So customers will always be interested in anonymity, and service 28:06.830 --> 28:11.090 providers will request for traceability, and you have to find a 28:11.090 --> 28:16.090 reasonable balance between these two interests. 28:17.930 --> 28:20.650 Online checking, why do we need online checking? 28:20.650 --> 28:25.790 We have the customer who presents stored values, we have the merchant 28:25.790 --> 28:31.770 who will accept this, this is true also for credit card-based payment 28:31.770 --> 28:37.770 systems, you want to purchase something, then the merchant calls the 28:37.770 --> 28:45.770 phone, calls the bank, and checks whether the customer is actually 28:45.770 --> 28:55.450 trustworthy, whether this amount is actually guaranteed by the bank or 28:55.450 --> 28:56.750 by the credit card company. 28:56.750 --> 29:02.610 And only then, if this is positive, this check, the merchant will 29:02.610 --> 29:05.230 provide the goods that are purchased. 29:06.570 --> 29:10.270 So the goal certainly is to minimize necessary complication for 29:10.270 --> 29:14.430 payment, you know that with our bank cards, some stores accept just 29:14.430 --> 29:19.990 the signature, others ask for your PIN, if it's PIN-based, you have 29:19.990 --> 29:24.090 the transactions with the bank, if you don't use the PIN, just the 29:24.090 --> 29:29.270 signature, you don't need this extra transaction with the bank, you 29:29.270 --> 29:32.270 can do that later, so different costs. 29:33.430 --> 29:37.690 And the alternative would be to do without online checking, but that 29:37.690 --> 29:40.910 would mean a larger risk for the credit card company, this is 29:40.910 --> 29:46.170 something you just have to estimate what the risk is and whether you 29:46.170 --> 29:53.270 want to take that risk, and then don't have these online checking 29:53.270 --> 29:55.550 transaction costs. 29:56.990 --> 30:03.970 So you would have, certainly if you don't have an online check, you 30:03.970 --> 30:07.010 still might have higher transaction costs because of higher insurance 30:07.010 --> 30:12.570 rates for your transactions, unless you say you don't want to insure 30:12.570 --> 30:18.970 your business with respect to these risks, but somewhere you will 30:18.970 --> 30:22.930 always have certain costs, because either you have the online 30:22.930 --> 30:28.770 checking, you have to pay for that, all this risk actually will be 30:28.770 --> 30:35.050 valid, that means some customers will actually use incorrect 30:35.050 --> 30:37.030 electronic balance. 30:38.570 --> 30:41.610 The acceptance of an electronic payment system is another point, 30:41.970 --> 30:48.770 acceptability, if a form of payment is only acceptable in very few 30:48.770 --> 30:53.150 places, nobody would use it, so the degree of acceptance of electronic 30:53.150 --> 30:58.150 payment is essential for the success of the system, and for the 30:58.150 --> 31:01.370 current situation, what is it, credit cards, certainly no problem, 31:01.550 --> 31:06.890 bank cards, widespread use, sometimes called F-Pause Electronic Fund 31:06.890 --> 31:11.990 Transfer at point of sale, this is something which we all use, I 31:11.990 --> 31:18.910 guess, or most of you would use, smart cards, used at some places, we 31:18.910 --> 31:21.890 don't have that many reading stations, so if you can deposit a certain 31:21.890 --> 31:26.810 amount of money on your bank card, then it's transformed into a money 31:26.810 --> 31:29.830 card, and you can pay with that. 31:29.830 --> 31:38.230 It is regularly used to a large extent, but it's not really that 31:38.230 --> 31:39.470 frequent. 31:39.530 --> 31:42.850 Who of you uses these Geldkarte? 31:45.350 --> 31:46.970 None of you use that? 31:47.170 --> 31:48.530 Okay, I don't use it. 31:49.830 --> 31:53.810 But in some places it's actually used much more. 31:53.810 --> 31:59.910 It somehow depends on the culture in some countries. 32:00.910 --> 32:06.990 Okay, electronic money is another thing that could be used. 32:07.750 --> 32:13.070 You know that some service providers, some internet providers, offer 32:13.070 --> 32:20.030 electronic coins to buy or to pay for services, this is some point of 32:20.030 --> 32:20.770 electronic money. 32:22.270 --> 32:26.890 The problem here is that electronic money usually is accepted only at 32:26.890 --> 32:31.930 very few banks, and this is a problem, you cannot use it as easily as 32:31.930 --> 32:33.750 you can use your cash. 32:34.490 --> 32:41.790 And we would like to have similar properties for electronic coins as 32:41.790 --> 32:43.530 for real coins. 32:44.890 --> 32:50.550 So an improvement of acceptability would be to have transfer of funds 32:50.550 --> 32:54.210 between different systems, which is a problem, it's not that easy. 32:55.010 --> 32:58.510 Or for example, the possibility to load your smart card using your 32:58.510 --> 33:04.190 mobile phone, this is something which is actually quite interesting, 33:04.410 --> 33:07.250 to use your mobile phone for payments. 33:07.670 --> 33:10.090 Several systems have been developed for that. 33:10.090 --> 33:13.230 You have certain levels of security in your mobile phone protocols, 33:13.830 --> 33:16.850 and these are used for payment purposes. 33:19.790 --> 33:24.310 Transferability of electronic means of payment, you have some money on 33:24.310 --> 33:28.290 your bank card, you want to transfer that to another person, this 33:28.290 --> 33:31.370 usually is impossible, you can only buy something for that and get 33:31.370 --> 33:36.930 some transaction, but you cannot just exchange your funds without the 33:36.930 --> 33:37.850 interference of the bank. 33:37.850 --> 33:43.210 Your credit card is of no help if you want to give some money to some 33:43.210 --> 33:43.890 other person. 33:45.890 --> 33:51.050 Certainly you can easily just hand over some amount of cash to another 33:51.050 --> 33:56.190 person, this is a very simple transfer of funds, this doesn't work 33:56.190 --> 33:59.730 like that in electronic forms of payment. 34:01.090 --> 34:02.930 So credit cards, no transfer possible. 34:03.090 --> 34:05.270 Smart cards, usually no transfer possible. 34:05.270 --> 34:09.130 For electronic money, there is a restricted transferability, depends 34:09.130 --> 34:16.130 on the trust you have in your partner in this transaction. 34:18.150 --> 34:24.770 And without the possibility of fund transfer, I think that electronic 34:24.770 --> 34:29.870 money will not really be able to compete with real money. 34:29.870 --> 34:35.250 There will always be only some areas where it actually will be used. 34:37.550 --> 34:43.070 So transferability obviously needs some open loop system, and the 34:43.070 --> 34:48.650 systems that are around usually are just first level or second level 34:48.650 --> 34:51.690 systems, but not the open loop systems. 34:52.830 --> 34:55.930 Another point is the divisibility of electronic means of payment. 34:56.550 --> 35:00.550 The traditional cash system has limited divisibility, just certain 35:00.550 --> 35:05.770 units are available, but you can just use multiple coins to get 35:05.770 --> 35:08.790 arbitrary values. 35:09.250 --> 35:13.570 So you must be able, if you store some value on your computer, you 35:13.570 --> 35:16.730 would like to be able to divide your money into arbitrary parts and 35:16.730 --> 35:17.070 fractions. 35:17.870 --> 35:21.970 This is essential for micropayments, you have to be able to pay very 35:21.970 --> 35:28.530 small amounts, and, well, if it's just the value that is stored, 35:28.670 --> 35:33.670 certainly you could just use real values, and you can store any 35:33.670 --> 35:41.690 amount, not really a problem, but, so you have to differentiate or 35:41.690 --> 35:47.110 distinguish between account based systems and units of electronic 35:47.110 --> 35:47.670 value. 35:48.190 --> 35:51.910 On an account based system you can have almost any amount, usually 35:51.910 --> 35:57.090 some integer value, and if you have units of electronic value, the 35:57.090 --> 36:01.830 question is what kind of units are necessary in order to be able to 36:01.830 --> 36:06.850 pay the amounts of money that you are charged if you want to purchase 36:06.850 --> 36:07.230 something. 36:08.770 --> 36:12.090 So, this is another point that has to be looked at. 36:12.990 --> 36:22.690 And we will now look at credit card systems, which are an accepted way 36:22.690 --> 36:23.290 of payment. 36:23.530 --> 36:27.850 There are certain payment protocols around, so the simplest would be 36:27.850 --> 36:34.670 just to use secure socket layer, essentially to use HTTPS. 36:36.230 --> 36:38.710 I will briefly explain that. 36:39.430 --> 36:43.350 There is an internet key payment protocol, which is actually more than 36:43.350 --> 36:43.570 that. 36:43.570 --> 36:48.050 So, SSR has really nothing to do, essentially, with, originally, with 36:48.050 --> 36:53.070 payments, just with making the communication over channels and the 36:53.070 --> 36:54.130 internet more secure. 36:55.310 --> 37:01.510 These internet key payment methods by IBM have been designed for 37:01.510 --> 37:06.190 payment, as the name says, and then there are these secure electronic 37:06.190 --> 37:13.930 transactions, which have been designed as payment methods by 37:13.930 --> 37:18.530 MasterCard and Visa, so it's specially designed for payments using 37:18.530 --> 37:19.210 credit cards. 37:19.550 --> 37:23.250 We will look more deeply into that. 37:24.310 --> 37:27.590 Then there are certain payment servers, first virtual and CyberCash, 37:28.350 --> 37:32.170 the first virtual one was the first virtual bank, which is no longer 37:32.170 --> 37:33.070 existing. 37:33.730 --> 37:40.090 CyberCash, this form of payment, is still around, as far as I know. 37:42.150 --> 37:46.110 Then, what kind of risks do we have when we transfer credit card 37:46.110 --> 37:46.430 numbers? 37:46.570 --> 37:50.810 Like we all, or most of us, will pay by credit card over the internet 37:50.810 --> 37:55.490 at some time, or some point, so the customer wants to order some goods 37:55.490 --> 38:00.270 or service on the internet, you want to get your train ticket, or 38:00.270 --> 38:03.730 things like that, and you want to pay using a credit card. 38:03.810 --> 38:04.470 What do you do? 38:05.370 --> 38:12.430 You get an HTML document, you provide input to some CGI script, and 38:12.430 --> 38:14.170 you provide credit card information. 38:14.290 --> 38:15.030 What do you provide? 38:15.190 --> 38:22.270 You usually provide just your credit card number, you provide the name 38:22.270 --> 38:26.890 of the holder of the credit card, and that's all. 38:26.890 --> 38:32.570 Now, to get a valid transaction with a credit card, you need the 38:32.570 --> 38:38.310 number, the holder of that credit card, and you need a signature. 38:39.290 --> 38:44.750 If you use a credit card on the internet, usually you don't provide a 38:44.750 --> 38:45.010 signature. 38:45.790 --> 38:46.890 So this is not valid. 38:49.170 --> 38:53.130 So transactions over the internet using your credit card are not 38:53.130 --> 38:55.950 really valid transactions. 38:57.470 --> 39:02.490 Nobody can charge you, actually, for purchasing something with a 39:02.490 --> 39:04.690 credit card, because you have not signed it. 39:05.910 --> 39:07.770 So the risk is totally with the merchant. 39:08.050 --> 39:12.730 He has to trust that, or has to hope, that actually the credit card 39:12.730 --> 39:16.990 company certainly will provide the money, but that the customer, in 39:16.990 --> 39:20.090 the end, will say, OK, I paid that. 39:21.170 --> 39:23.230 But the risk is totally with the merchant. 39:24.250 --> 39:31.850 That's a problem with most internet shops, that they bear the risk of 39:31.850 --> 39:37.990 incorrect use of credit cards, and, well, certainly it's lots of 39:37.990 --> 39:43.570 hassles if you get incorrect transactions on a credit card, and you 39:43.570 --> 39:49.850 say, OK, this is not my credit card, but I have not authorized this 39:49.850 --> 39:50.310 transaction. 39:51.150 --> 39:54.830 But still, the risk is actually with the merchant. 39:55.050 --> 39:56.070 So possibly the tax. 39:57.230 --> 40:03.610 The attacker would eavesdrop the datagram with credit card information 40:03.610 --> 40:04.790 from the internet. 40:04.890 --> 40:08.010 You can always monitor the datagrams. 40:08.010 --> 40:15.010 If you know there is a site where there are many, or where a lot of 40:15.010 --> 40:18.690 data is sent containing credit card information, you could just 40:18.690 --> 40:25.730 intercept that link and check all of these datagrams, which is easily 40:25.730 --> 40:26.090 done. 40:26.290 --> 40:30.390 There are standard programs around for doing that, for checking the 40:30.390 --> 40:33.790 contents of datagrams, so you could easily collect credit card 40:33.790 --> 40:34.210 information. 40:35.790 --> 40:40.710 So another point would be just to modify the CGI script on the system 40:40.710 --> 40:46.990 and make sure that you don't really have to intercept the line, but 40:46.990 --> 40:50.870 you just manage to have a copy of this credit card information sent to 40:50.870 --> 40:53.710 your own server. 40:54.790 --> 40:56.810 And then you get all the credit card information. 40:56.810 --> 41:03.510 You get lots of credit cards and can attack or perform certain 41:03.510 --> 41:08.450 attacks, use these credit card information in an incorrect way. 41:09.170 --> 41:10.270 So how could you protect? 41:10.870 --> 41:15.630 By using authentication, as we know, providing digital signatures, or 41:15.630 --> 41:20.270 to encrypt the contents of this credit card information. 41:20.870 --> 41:28.470 Encryption is used if you have SSL in there, secure, secure socket 41:28.470 --> 41:33.530 layer, and certainly you could use authentication of this credit card 41:33.530 --> 41:35.310 information to make it more secure. 41:36.310 --> 41:41.130 By the way, when you, in our daily life, we use our credit cards, we, 41:41.730 --> 41:45.430 at some places, or at many places, we just provide complete 41:45.430 --> 41:47.070 information about our credit card. 41:47.070 --> 41:51.530 We provide the number, our name, and the signature. 41:51.750 --> 41:55.570 When we pay at a gas station, for example, or at a restaurant, we just 41:55.570 --> 41:58.310 provide the information, which is everything. 41:58.570 --> 42:02.470 It's even the signature, which could be used by the recipient of that 42:02.470 --> 42:06.550 payment slip to use it for his purpose. 42:07.490 --> 42:13.070 So this is, there's more risk associated with that than with providing 42:13.070 --> 42:15.010 your credit card information over the internet. 42:15.010 --> 42:23.330 Nobody is objecting to providing this payment slip to the person at 42:23.330 --> 42:26.910 the gas station, because you trust it will not be misused. 42:27.130 --> 42:32.670 But it could be misused, because on this payment slip, you have all 42:32.670 --> 42:36.050 the information that is necessary to actually perform a transaction. 42:38.770 --> 42:44.810 Okay, that's a bit about the risks of the use of credit cards. 42:45.750 --> 42:49.270 I would now like to come to a few protocols that are in use. 42:49.890 --> 42:53.510 Secure Socket Layer is one protocol that has been developed by 42:53.510 --> 42:58.850 Netscape to make transactions over, or by, if you use a browser, more 42:58.850 --> 42:59.290 secure. 43:00.330 --> 43:06.230 It has been extended to the Transport Layer security, which is just a 43:06.230 --> 43:09.390 more general protocol than the Secure Socket Layer. 43:11.510 --> 43:16.030 So you can look it up in all details in the appropriate RFC. 43:17.350 --> 43:22.110 And what the Transport Layer security does is just to provide secure 43:22.110 --> 43:28.110 communication over insecure channels, just above TCP IP. 43:28.110 --> 43:36.290 So we have TCP, and above that we have TLS or SSL. 43:37.030 --> 43:42.630 So it's just above the TCP layer, and the application is on top of 43:42.630 --> 43:42.870 that. 43:45.010 --> 43:51.030 So in this area here, there's no security, there's just security for 43:51.030 --> 43:52.450 the TCP part. 43:52.450 --> 43:58.430 So TCP only gets encrypted information using this TLS. 43:59.830 --> 44:05.750 So you get client-server authentication, make sure that you have an 44:05.750 --> 44:11.470 appropriate recipient, or appropriate partners in the communication 44:11.470 --> 44:13.930 between the two hosts. 44:14.330 --> 44:20.050 If you have your logical connection here, sender and receiver, you 44:20.050 --> 44:29.110 want to make sure that it's really the recipient that you expect it to 44:29.110 --> 44:29.370 be. 44:30.090 --> 44:33.790 We use digital signatures, we use encryption of documents, and that 44:33.790 --> 44:37.150 way we have secure communication over that logical line. 44:37.870 --> 44:42.210 We use the common combination of asymmetric and symmetric methods, as 44:42.210 --> 44:45.890 we have seen in the final protocol that I presented to you in the last 44:45.890 --> 44:47.710 slide on the cryptographics chapter. 44:47.710 --> 44:53.390 So it uses RSA, Diffie-Hellman, which I didn't present to you, another 44:53.390 --> 45:01.910 asymmetric encryption method, and then these various RC, realist 45:01.910 --> 45:08.630 cryptographic methods are used, RC2, RC4, MD5, SHA, you know, these 45:08.630 --> 45:09.530 message digests. 45:10.290 --> 45:13.070 So digital signatures are used with standard methods. 45:13.790 --> 45:22.630 So there is a collection of algorithms that is used, and in the 45:22.630 --> 45:28.730 initial handshake protocol that is performed when the logic connection 45:28.730 --> 45:34.330 is established, client and server have to agree about the level of 45:34.330 --> 45:39.870 security they want to apply, so they agree upon the strongest 45:39.870 --> 45:43.810 cryptographic methods that are available to both of them. 45:44.270 --> 45:48.010 Maybe the other client doesn't have all these methods available, but 45:48.010 --> 45:54.070 you always get the highest level of security by certain negotiation in 45:54.070 --> 45:56.010 the beginning of the connection. 45:57.310 --> 46:02.330 And the HTTP user certainly can switch to SSL by just selecting HTTPS, 46:02.330 --> 46:08.710 if that is supported by the other side, then you get secure 46:08.710 --> 46:12.610 transactions over the logical link, which is certainly more than just 46:12.610 --> 46:17.490 plain communication, but it's not complete security, because you still 46:17.490 --> 46:20.190 have the possibility that somebody interferes with the application 46:20.190 --> 46:25.030 systems on your server, and as soon as you are inside your system, 46:26.010 --> 46:33.790 about this socket, then you have no longer any security. 46:34.310 --> 46:39.610 You just have the security in between these two hosts that are 46:39.610 --> 46:40.910 connected by that link. 46:42.050 --> 46:49.910 This SSL handshake protocol is working in an obvious way. 46:50.050 --> 46:56.330 Client and server have to communicate, so the client sends a message 46:56.330 --> 47:01.150 that he wants to communicate with the server, wants to access a 47:01.150 --> 47:01.830 certain service. 47:02.510 --> 47:09.690 The server will respond to that request, to that hello message, by 47:09.690 --> 47:14.350 providing his certificate, will request for a certificate from the 47:14.350 --> 47:20.910 client, and will also exchange certain keys with a certificate. 47:20.910 --> 47:25.170 We know how you have to exchange your public key, you have to provide 47:25.170 --> 47:30.010 a certificate, such that the recipient actually can check whether that 47:30.010 --> 47:36.870 is a valid public key, and then this is checked. 47:37.690 --> 47:51.070 The client will also send his certificate and his key, and the cipher 47:51.070 --> 47:58.870 specifications have to be agreed on, so the client tells what kind of 47:58.870 --> 48:04.130 cryptographic methods are available to the client, and the server will 48:04.130 --> 48:09.670 have to agree on that, so here the server has to also agree to the 48:09.670 --> 48:16.250 cipher specification that is provided by the client, and then they 48:16.250 --> 48:20.130 have agreed upon the methods they use, they have checked their 48:20.130 --> 48:25.590 certificates, they can exchange application data over protected 48:25.590 --> 48:28.230 channels, so this part here then is protected. 48:28.430 --> 48:33.410 Before that it's not protected, after that session keys are used to 48:33.410 --> 48:38.130 encrypt the information that is sent between two points. 48:40.330 --> 48:47.350 Okay, so I don't go into the details of this protocol, it's just to 48:47.350 --> 48:51.250 indicate what is done initially here. 48:52.050 --> 48:55.790 They have to exchange certificates, make sure that they know the 48:55.790 --> 48:59.750 correct public key, they have seen different methods of doing that, to 48:59.750 --> 49:05.950 produce the interlock protocol, or use some certificate system, you 49:05.950 --> 49:10.510 need some public key infrastructure for that, and this is done by 49:10.510 --> 49:16.150 server and client automatically, and then they agree upon the 49:16.150 --> 49:20.830 cryptographic system that is used, and exchange application data in an 49:20.830 --> 49:21.430 encrypted way. 49:22.670 --> 49:28.030 Okay, that's all on SSL, I didn't want to provide more information on 49:28.030 --> 49:31.710 that, because the more application-oriented system is the Secure 49:31.710 --> 49:37.990 Chronic Transaction System, SET, which is developed for secure 49:37.990 --> 49:43.050 exchange of information with respect to purchasing something with 49:43.050 --> 49:48.390 credit card, so it's been designed for secure exchange of information 49:48.390 --> 49:52.830 in the context of executing business transactions using credit card, 49:52.910 --> 49:58.810 as I said, requirements are that, well, you have confidentiality of 49:58.810 --> 50:04.230 information with respect to the payment event and the purchase order, 50:04.330 --> 50:10.330 something which usually is not the case if you have normal credit card 50:10.330 --> 50:14.350 transactions, you don't have confidentiality of this information, 50:14.350 --> 50:21.250 usually the payment event is visible to the merchant, to the bank, the 50:21.250 --> 50:24.230 purchase order is also visible to the bank or the credit card company, 50:25.150 --> 50:32.150 and this is something which is just prevented by the system. 50:32.330 --> 50:36.070 So, confidentiality is a new requirement for these credit card 50:36.070 --> 50:39.650 transactions, it says that it's guaranteed by encrypting messages, 50:39.650 --> 50:47.870 VES, now this will be done by AES, data integrity has to be guaranteed 50:47.870 --> 50:55.370 that the messages sent on credit card information are not manipulated, 50:56.090 --> 51:00.410 we know how to do that by using digital signatures, and merchant and 51:00.410 --> 51:04.990 customer have to be authenticated, we have to know that actually a 51:04.990 --> 51:09.150 specific customer is providing this credit card information and the 51:09.150 --> 51:13.250 merchant also has to identify himself, so we need authentication of 51:13.250 --> 51:13.870 both sides. 51:15.130 --> 51:22.410 So the merchant might want to find out whether the customer is really 51:22.410 --> 51:26.670 owning a valid credit card account, and the customer would like to 51:26.670 --> 51:29.730 know whether the merchant is authorized to accept credit cards or 51:29.730 --> 51:34.550 whether there is something known that this merchant does wrong things 51:34.550 --> 51:34.730 with. 51:36.290 --> 51:40.070 Now these requirements can be met by using essentially the protocol 51:40.070 --> 51:47.310 that I presented to you in the last slide, or the last chapter, but we 51:47.310 --> 51:53.050 will look at the details of this protocol, which use this secure 51:53.050 --> 51:57.650 communication protocol in a very sophisticated way, as you will see in 51:57.650 --> 52:03.330 a moment, uses digital signatures and certificates of card owners and 52:03.330 --> 52:07.250 merchants, and we will now go into that system. 52:07.610 --> 52:11.910 We have three participants, customer, the merchant, and the bank, or 52:11.910 --> 52:18.310 you could say bank, which is something which is just a combination of 52:18.310 --> 52:22.250 a credit card company and the actual bank that is making that money 52:22.250 --> 52:22.710 transfer. 52:22.710 --> 52:27.110 So the customer will initiate a request, the merchant will respond to 52:27.110 --> 52:32.650 that, provide some information, the customer will order some goods, 52:32.990 --> 52:36.590 will provide a purchase order, the merchant will respond to that 52:36.590 --> 52:44.690 purchase, and the merchant will ask for authorization of that request, 52:45.230 --> 52:49.470 check with the credit card company whether the customer is good for 52:49.470 --> 52:54.910 that amount, the bank will come back with the authorization response, 52:55.770 --> 53:00.790 the customer may check for the status, the merchant will respond to 53:00.790 --> 53:08.650 that, and when the merchant got a positive response, and at some later 53:08.650 --> 53:17.190 time, the merchant will try to get actually the money that should be 53:17.190 --> 53:23.050 transferred, and the bank will respond with the payment capture 53:23.050 --> 53:23.750 response. 53:24.250 --> 53:28.910 Now we have to look at all these ten things that actually have to be 53:28.910 --> 53:33.790 performed and see how that is implemented in the secure electronic 53:33.790 --> 53:34.810 transactions protocol. 53:36.470 --> 53:42.450 It is done in a way such that, first of all, every participant has two 53:42.450 --> 53:43.950 public key pairs. 53:43.950 --> 53:47.450 Not just one public key pair, but two public key pairs. 53:47.770 --> 53:51.190 One is used exclusively for digital signatures. 53:52.230 --> 53:56.290 The other one is used for sending session keys. 53:57.050 --> 54:03.210 So not just one pair of keys, but two pairs of keys, and these public 54:03.210 --> 54:09.010 keys are verified using some certification hierarchy, so you need some 54:09.010 --> 54:16.030 certificate, as we have seen last week, you need these certified 54:16.030 --> 54:21.170 certificates signed by some certification authority. 54:22.810 --> 54:32.930 And then the purchase order that is provided by the customer looks 54:32.930 --> 54:34.550 essentially like this. 54:34.550 --> 54:38.310 We have a customer message for the merchant containing the ordering 54:38.310 --> 54:43.990 information, and we have a message of the customer to the bank with 54:43.990 --> 54:45.330 respect to the payment information. 54:45.570 --> 54:49.510 So the customer knows how much money has to be paid, and the only 54:49.510 --> 54:56.930 thing that the merchant needs is the information on the type of 54:56.930 --> 54:59.810 product that the customer wants to buy. 55:01.470 --> 55:08.290 The merchant does not need to know anything about the account of the 55:08.290 --> 55:08.710 customer. 55:09.210 --> 55:11.830 The merchant only needs the money in some point of time. 55:12.410 --> 55:15.190 But it's not necessary for the merchant actually to know the credit 55:15.190 --> 55:17.310 card number or anything like that. 55:18.410 --> 55:22.490 This is something which has to do with the increase in amenity that 55:22.490 --> 55:25.370 should be included in this system. 55:26.130 --> 55:30.550 So we have these two parts, these two messages, these separate 55:30.550 --> 55:34.990 messages, and we get message digests of these two parts. 55:35.070 --> 55:39.110 The message digest of the order information, the message digest of the 55:39.110 --> 55:39.830 payment information. 55:40.290 --> 55:43.210 And then we compute a digest of these digests. 55:43.750 --> 55:49.810 So these two message digests are combined, and then this is signed 55:49.810 --> 55:51.350 actually... 55:51.350 --> 55:56.970 So this final digest, this digest of the digest, is encrypted with a 55:56.970 --> 55:59.990 secret key of the customer. 56:00.430 --> 56:05.110 He uses this private key and provides a digital signature, a so-called 56:05.110 --> 56:13.430 dual signature, because this signature contains information about both 56:13.430 --> 56:18.470 messages, the order information and the payment information. 56:18.470 --> 56:25.750 And we will see how that dual signature is actually used to satisfy 56:25.750 --> 56:30.790 the requirements that are initially to make sure that the ordering 56:30.790 --> 56:33.930 information is only available to the merchant, and the payment 56:33.930 --> 56:37.970 information is hidden from the merchant and only available to the 56:37.970 --> 56:38.170 bank. 56:39.190 --> 56:44.070 So, but also, like the customer message to the bank is encrypted, 56:45.850 --> 56:51.530 because certainly the customer has to send the information to the 56:51.530 --> 56:51.810 merchant. 56:52.710 --> 56:55.790 And if you want to hide this information from the merchant, you have 56:55.790 --> 56:59.410 to encrypt it in some way, so he uses the session key, some symmetric 56:59.410 --> 57:06.770 method, and he also uses the bank's public key to encrypt the session 57:06.770 --> 57:12.290 key, such that only the bank will be able to decrypt the payment 57:12.290 --> 57:16.750 information, and the merchant will not be able to decrypt that payment 57:16.750 --> 57:17.230 information. 57:19.010 --> 57:23.890 So the merchant can only read his part of the message, and the 57:23.890 --> 57:28.470 encrypted payment information, the dual signature, and the hidden 57:28.470 --> 57:32.470 session key have to be forwarded to the bank, and the bank then can 57:32.470 --> 57:34.810 access the payment information. 57:35.290 --> 57:37.570 It does not get the ordering information. 57:37.990 --> 57:38.910 It doesn't need that. 57:38.990 --> 57:43.870 It only needs information, well, a certain customer would like to have 57:43.870 --> 57:45.230 this untransferred. 57:45.910 --> 57:50.970 The bank shouldn't bother about the type of product that is actually 57:50.970 --> 57:51.330 ordered. 57:53.110 --> 57:56.850 So payment information is hidden from the merchant, ordering 57:56.850 --> 58:05.870 information is hidden from the bank, and so this way we get certainly 58:05.870 --> 58:11.410 an additional level of anonymity, a higher level of security than with 58:11.410 --> 58:15.430 the standard credit card transaction protocols. 58:16.430 --> 58:19.150 Here again, the communication scheme. 58:20.130 --> 58:26.330 So the cardholder initiates a request, and sends it to the merchant, 58:26.830 --> 58:31.950 and then the merchant sends certificates back to the cardholder. 58:32.510 --> 58:37.830 The cardholder will receive the response and send the request 58:37.830 --> 58:40.530 containing the ordering information. 58:41.710 --> 58:46.990 The purchase request is received by the merchant, it's processed, and 58:46.990 --> 58:49.890 the merchant responds in the appropriate way. 58:50.010 --> 58:53.330 We will now look at the way this actually is implemented. 58:54.490 --> 59:07.690 So this is the first response that is sent from the merchant to the 59:07.690 --> 59:08.190 cardholder. 59:09.770 --> 59:12.710 This is the second transaction there. 59:13.450 --> 59:16.250 What does the merchant have to send to the customer? 59:16.870 --> 59:23.750 The merchant sends some information, it's not essential what is in 59:23.750 --> 59:28.030 that information, we just look at the cryptographic things in here. 59:29.850 --> 59:33.710 It has to make sure that you can check the integrity of that message, 59:33.710 --> 59:37.370 so you need a signature of that message. 59:38.210 --> 59:43.370 We provide the message digest, encrypt the message digest, get a 59:43.370 --> 59:50.930 digital signature of that initial response message, and the merchant 59:50.930 --> 59:55.150 sends his initial response message and this digital signature. 59:55.470 --> 01:00:00.410 So this signature here is provided, or is sent with a message to the 01:00:00.410 --> 01:00:00.810 customer. 01:00:00.810 --> 01:00:06.710 And the merchant has to make sure that the customer actually can 01:00:06.710 --> 01:00:11.370 access the digital signature, so he has to provide his certificate 01:00:11.370 --> 01:00:17.550 containing information on his public key, the key that is used for 01:00:17.550 --> 01:00:18.250 digital signature. 01:00:18.510 --> 01:00:23.510 So this is the merchant certificate signature key, for his signature 01:00:23.510 --> 01:00:23.890 key. 01:00:24.890 --> 01:00:29.930 He also would like to get information from the... 01:00:29.930 --> 01:00:36.550 or he wants to allow the customer to send his payment information to 01:00:36.550 --> 01:00:38.730 the bank that he is associated with. 01:00:39.890 --> 01:00:46.810 So the payment gateway certificate key has to be provided to the 01:00:46.810 --> 01:00:51.250 cardholder, so it's the payment gateway certificate for the key 01:00:51.250 --> 01:00:51.850 exchange. 01:00:53.190 --> 01:00:57.570 As I said, the payment information will be encrypted using a session 01:00:57.570 --> 01:01:04.470 key, and the session key will be encrypted using the public key of the 01:01:04.470 --> 01:01:10.630 payment of this bank, so it is the payment gateway's key exchange key, 01:01:12.930 --> 01:01:17.410 or this public key for exchanging the session key. 01:01:18.330 --> 01:01:25.070 So the cardholder will get that information, and what will he do? 01:01:25.630 --> 01:01:34.990 He can extract the initial message, can compute the digest, he will 01:01:34.990 --> 01:01:42.450 retrieve the public key from the merchant using this certificate, can 01:01:42.450 --> 01:01:50.590 get the public signature key of the merchant, can decrypt the digital 01:01:50.590 --> 01:01:55.670 signature, get the message digest, compare that message digest with 01:01:55.670 --> 01:01:59.270 the message digest that was computed from the initial message here, 01:01:59.270 --> 01:02:04.590 and if that coincides, you have checked the integrity of that initial 01:02:04.590 --> 01:02:05.070 message. 01:02:06.370 --> 01:02:08.170 And that's all that has to be done. 01:02:08.370 --> 01:02:14.030 And then he will compile his information, he will compile the purchase 01:02:14.030 --> 01:02:20.590 order, and this consists of the ordering information, the previous OI, 01:02:20.790 --> 01:02:26.930 the payment information, and now we know we have to make sure that we 01:02:26.930 --> 01:02:32.430 get this dual signature, so we compute the message digest for the 01:02:32.430 --> 01:02:35.390 ordering information, the message digest for the payment information, 01:02:36.170 --> 01:02:42.070 both are again hashed to get the combined message digest, which is 01:02:42.070 --> 01:02:47.510 encrypted by the cardholder's private signature key, to get this dual 01:02:47.510 --> 01:02:47.950 signature. 01:02:49.450 --> 01:02:58.290 Now the payment information should be encrypted, so we need... 01:02:58.290 --> 01:03:01.010 we have to encrypt this information. 01:03:01.270 --> 01:03:04.590 This is done, the fully-encrypted payment information, and the dual 01:03:04.590 --> 01:03:09.750 signature, actually, are both encrypted using some symmetric key, a 01:03:09.750 --> 01:03:17.190 session key, and this encrypted payment message is put into this 01:03:17.190 --> 01:03:25.750 request message, this purchase order, then the payment information 01:03:25.750 --> 01:03:35.090 message digest, so this message digest here, is also included, because 01:03:35.090 --> 01:03:41.890 certainly the merchant must have a way of checking whether this 01:03:41.890 --> 01:03:48.670 payment information that he cannot decrypt contains the correct 01:03:48.670 --> 01:03:49.290 information. 01:03:52.110 --> 01:03:56.750 So, we must have a connection of the ordering information and the 01:03:56.750 --> 01:04:00.070 payment information, the merchant must have some access to the payment 01:04:00.070 --> 01:04:05.750 information, but he only gets it with this message digest of this 01:04:05.750 --> 01:04:06.490 payment information. 01:04:06.750 --> 01:04:10.030 We'll see how that is actually used to make sure that nothing can be 01:04:10.030 --> 01:04:11.450 manipulated here. 01:04:12.490 --> 01:04:15.750 What else does the purchase order need? 01:04:15.750 --> 01:04:25.010 So, you have to encrypt the symmetric key that is used for encrypting 01:04:25.010 --> 01:04:29.850 the payment information, and the account data of the customer 01:04:29.850 --> 01:04:35.010 certainly also has to be provided to the bank, the account number and 01:04:35.010 --> 01:04:39.350 all kinds, maybe the name of the customer, and so on. 01:04:39.350 --> 01:04:46.010 And this is encrypted using the payment gateway's public key exchange 01:04:46.010 --> 01:04:47.010 key. 01:04:47.590 --> 01:04:51.170 This has been provided in this certificate that the merchant sent in 01:04:51.170 --> 01:04:52.930 the initial response. 01:04:53.810 --> 01:04:59.470 And so you have your encrypted session key and the encrypted account 01:04:59.470 --> 01:05:00.050 information. 01:05:00.670 --> 01:05:06.210 This is put into, or this then is what is called here payment digital 01:05:06.210 --> 01:05:06.810 envelope. 01:05:06.810 --> 01:05:13.190 You have the digital, call it digital envelope, because this is the 01:05:13.190 --> 01:05:17.310 envelope that has to be opened in order to provide access to this 01:05:17.310 --> 01:05:25.050 encrypted message that is contained in this request message to the 01:05:25.050 --> 01:05:28.370 merchant, which has to be forwarded later on to the bank. 01:05:29.930 --> 01:05:33.450 Now certainly the ordering information has to be sent to the merchant. 01:05:33.450 --> 01:05:36.190 This is done here, that's the ordering information. 01:05:37.010 --> 01:05:40.970 And we also have to provide the dual signature. 01:05:42.910 --> 01:05:45.930 So this dual signature is provided twice. 01:05:46.510 --> 01:05:53.370 Once in encrypted form, here in this part, that is forwarded to the 01:05:53.370 --> 01:06:00.190 payment gateway, and in plain form, here this dual signature to the 01:06:00.190 --> 01:06:00.930 merchant. 01:06:00.930 --> 01:06:07.030 And then the cardholder has to provide his own certificate about his 01:06:07.030 --> 01:06:12.530 signature key, because he sent this digital signature, it has to be 01:06:12.530 --> 01:06:14.130 checked for that in the public key. 01:06:14.590 --> 01:06:16.410 And all this now is sent to the merchant. 01:06:17.650 --> 01:06:22.490 The merchant gets all this, extracts the information, extracts the 01:06:22.490 --> 01:06:23.770 information in a normal way. 01:06:24.370 --> 01:06:29.490 So he wants to check the validity, the integrity of the information, 01:06:29.490 --> 01:06:30.610 how can he do that? 01:06:31.390 --> 01:06:40.690 He can compute the digest from the ordering information, and get the 01:06:40.690 --> 01:06:42.370 ordering information message digest. 01:06:43.430 --> 01:06:48.210 And now, since the payment information message digest was contained in 01:06:48.210 --> 01:06:56.170 that message, the merchant can combine those two digests, he can 01:06:56.170 --> 01:07:03.470 compute the combined message digest, he can retrieve the dual 01:07:03.470 --> 01:07:08.370 signature, decrypt that using the cardholder's public key for the 01:07:08.370 --> 01:07:17.330 signature key, get back the combined message digest, and compare both 01:07:17.330 --> 01:07:26.030 to check the validity of this information that he got. 01:07:26.170 --> 01:07:27.370 So what does he actually check? 01:07:27.410 --> 01:07:32.590 He checks the validity of the ordering information, and he checks 01:07:32.590 --> 01:07:38.730 whether this has been combined with the payment information in an 01:07:38.730 --> 01:07:39.510 appropriate way. 01:07:39.510 --> 01:07:44.750 So if this actually, if the signature is correct, so he only sees the 01:07:44.750 --> 01:07:48.970 ordering information so far, he has not seen the payment information. 01:07:52.570 --> 01:07:55.130 OK, that's all he can do with this. 01:07:55.450 --> 01:07:59.930 And then he acts according to all this information. 01:08:00.710 --> 01:08:08.450 He will respond to the cardholder by providing some purchase response, 01:08:08.450 --> 01:08:13.810 which again is provided with a digital signature. 01:08:14.350 --> 01:08:20.070 He sends both to the cardholder, and again he sends his signature key 01:08:20.070 --> 01:08:20.690 certificate. 01:08:21.550 --> 01:08:28.690 The cardholder can check that in the normal way, just by computing a 01:08:28.690 --> 01:08:32.750 message digest, decrypting the signature, getting the message digest 01:08:32.750 --> 01:08:37.170 that had been provided by the merchant, he can compare both, and then 01:08:37.170 --> 01:08:41.330 he gets this data integrity check. 01:08:42.470 --> 01:08:48.170 Now this was the communication between cardholder and merchant. 01:08:48.450 --> 01:08:50.470 Now we have to look at the payment authorization. 01:08:51.310 --> 01:08:55.750 The merchant has to send information to the payment gateway to get 01:08:55.750 --> 01:08:57.150 authorization for the payment. 01:08:57.730 --> 01:09:03.170 So he sends an authorization request, and the payment gateway will 01:09:03.170 --> 01:09:05.350 answer with an authorization response. 01:09:05.550 --> 01:09:11.010 Either the cardholder is good for that amount of money or not, and the 01:09:11.010 --> 01:09:17.150 merchant will process this response, then it will continue with the 01:09:17.150 --> 01:09:18.690 communication with the customer. 01:09:19.670 --> 01:09:23.070 So the authorization request will contain the following information. 01:09:23.070 --> 01:09:28.350 Suddenly the bank will have to get the payment information. 01:09:29.830 --> 01:09:39.250 So the authorization, the payment information is in here. 01:09:39.350 --> 01:09:44.830 That was the encrypted payment message that had been sent by the 01:09:44.830 --> 01:09:45.630 customer. 01:09:46.450 --> 01:09:49.850 The customer had also sent this payment digital envelope. 01:09:49.850 --> 01:09:53.430 So this is just forwarded by the merchant to the payment gateway. 01:09:54.270 --> 01:09:58.110 And the merchant provides some additional information. 01:09:58.770 --> 01:10:01.950 The merchant will provide some authorization request containing 01:10:01.950 --> 01:10:05.290 information on the amount of money he actually wants to get. 01:10:06.990 --> 01:10:11.030 The bank certainly has to be able to check whether these two amounts 01:10:11.030 --> 01:10:12.070 of money coincide. 01:10:12.070 --> 01:10:19.130 This is, again, secure using this digital signature computation. 01:10:20.390 --> 01:10:28.990 And then both actually is encrypted using a symmetric key, session 01:10:28.990 --> 01:10:29.370 key. 01:10:29.370 --> 01:10:38.750 And so you have here a symmetric key that is used, this is the session 01:10:38.750 --> 01:10:41.770 key for encrypting the authorization request and the digital 01:10:41.770 --> 01:10:42.250 signature. 01:10:43.550 --> 01:10:52.150 And this symmetric key then is used, or is encrypted using the payment 01:10:52.150 --> 01:10:57.330 gateway's public key for the key exchange. 01:10:57.330 --> 01:11:03.550 And this then is the digital envelope for this encrypted authorization 01:11:03.550 --> 01:11:04.270 request. 01:11:05.370 --> 01:11:07.890 This has to be sent to the bank. 01:11:09.130 --> 01:11:12.450 And the merchant also has to provide a few certificates. 01:11:13.190 --> 01:11:18.030 He has to provide the cardholder's certificate for the signature key, 01:11:18.270 --> 01:11:22.470 because the bank has to be able to retrieve the information. 01:11:22.470 --> 01:11:29.930 The merchant's certificate for his own signature, and the merchant's 01:11:29.930 --> 01:11:32.650 certificate for his key exchange. 01:11:42.590 --> 01:11:51.070 Later on, the bank will provide back some information to the merchant 01:11:51.070 --> 01:11:53.490 where the bank needs this certificate. 01:11:54.330 --> 01:11:55.970 This is sent to the payment gateway. 01:11:55.970 --> 01:12:01.670 The payment gateway is actually then using all this information. 01:12:02.430 --> 01:12:05.750 It's decrypting, well it cannot decrypt the information, it first has 01:12:05.750 --> 01:12:07.330 to open the envelope. 01:12:07.790 --> 01:12:11.430 It can open the envelope by using its own private key for a key 01:12:11.430 --> 01:12:12.030 exchange. 01:12:12.810 --> 01:12:17.090 And then decrypt this authorization request, get the authorization 01:12:17.090 --> 01:12:27.210 request, and check again whether the two message dialogues coincide. 01:12:27.930 --> 01:12:30.890 So this is again the standard protocol. 01:12:31.470 --> 01:12:36.610 This key here, the merchant's public signature key, is retrieved from 01:12:36.610 --> 01:12:37.690 the appropriate certificate. 01:12:39.350 --> 01:12:41.730 And what else has to be done? 01:12:41.730 --> 01:12:45.550 The encrypted message from the customer has to be, or from the 01:12:45.550 --> 01:12:48.850 cardholder, has to be retrieved by the payment gateway. 01:12:49.490 --> 01:12:54.710 So this is decrypted using the symmetric key that is obtained from the 01:12:54.710 --> 01:12:55.550 digital envelope. 01:12:55.950 --> 01:13:00.590 The digital envelope, the payment envelope, could be opened by the 01:13:00.590 --> 01:13:05.570 payment gateway's secret key for key exchange. 01:13:05.570 --> 01:13:13.410 The payment gateway's private key exchange key decrypts the session 01:13:13.410 --> 01:13:19.210 key, decrypts the message, gets the payment information, also gets the 01:13:19.210 --> 01:13:22.970 dual signature, which is also contained in that payment message. 01:13:22.970 --> 01:13:34.890 And again, the payment information can be checked by using, or by 01:13:34.890 --> 01:13:41.150 writing this, or by combining, or by computing this message dialogues 01:13:41.150 --> 01:13:42.170 of the payment information. 01:13:43.010 --> 01:13:47.790 And now certainly, up here, there was, or somewhere here, was the dual 01:13:47.790 --> 01:13:48.310 signature. 01:13:49.730 --> 01:13:56.630 And so you can retrieve the combined message digest, but to be able to 01:13:56.630 --> 01:14:01.090 compare that with the combined message digest that was originally 01:14:01.090 --> 01:14:06.450 computed by the customer, you also need the authorization, the 01:14:06.450 --> 01:14:08.110 ordering information message digest. 01:14:08.390 --> 01:14:12.010 This is retrieved, actually, from the authorization request. 01:14:12.010 --> 01:14:18.530 So the merchant had to provide also this ordering information message 01:14:18.530 --> 01:14:18.910 digest. 01:14:19.310 --> 01:14:25.530 Then the payment gateway can combine both and get this message digest 01:14:25.530 --> 01:14:26.970 of the combined information. 01:14:27.510 --> 01:14:31.110 So here we have the connection of the payment information with the 01:14:31.110 --> 01:14:35.450 ordering information, but it's not directly connected, but through 01:14:35.450 --> 01:14:37.490 these digests. 01:14:37.490 --> 01:14:39.490 Then this can be compared. 01:14:39.750 --> 01:14:44.750 The payment gateway knows that the dual signature connected, actually, 01:14:45.250 --> 01:14:46.110 correct information. 01:14:47.470 --> 01:14:53.390 The merchant could not interfere with this process because it could 01:14:53.390 --> 01:14:56.150 not provide a false message digest here. 01:14:56.990 --> 01:14:59.770 So this is a valid integrity check. 01:15:01.050 --> 01:15:04.650 And now the payment gateway has all the information it needs. 01:15:04.650 --> 01:15:08.970 It has the cardholder account information, can check whether the 01:15:08.970 --> 01:15:10.990 cardholder is valid for that amount. 01:15:12.190 --> 01:15:19.490 And so the cardholder, or the payment gateway, is checking whether the 01:15:19.490 --> 01:15:24.350 cardholder's financial institution, the issuer of that credit card, 01:15:24.470 --> 01:15:32.770 actually says the customer has sufficient balance on his account and 01:15:32.770 --> 01:15:33.910 can proceed. 01:15:34.770 --> 01:15:38.950 And then the authorization response is computed, and here we get 01:15:38.950 --> 01:15:40.550 another interesting point. 01:15:40.970 --> 01:15:41.890 We should wake up again. 01:15:43.090 --> 01:15:46.970 Some of you have almost fallen asleep because I'm talking too quickly, 01:15:47.670 --> 01:15:49.410 and it's always the same protocol. 01:15:49.410 --> 01:15:54.410 But here's something contained which is actually of interest, because 01:15:54.410 --> 01:15:59.370 there's the notion of how actually the merchant will get its money. 01:16:00.410 --> 01:16:05.770 And to provide that, you need a specific method to do that. 01:16:05.970 --> 01:16:08.710 So what does the payment gateway do? 01:16:09.270 --> 01:16:16.830 It provides the authorization response, telling the cardholder it's 01:16:16.830 --> 01:16:18.010 good for that money, for example. 01:16:18.010 --> 01:16:24.830 This is again encrypted using some session key. 01:16:25.710 --> 01:16:27.570 Nobody else should look at that information. 01:16:27.930 --> 01:16:30.570 So it is encrypted with a symmetric key. 01:16:30.730 --> 01:16:34.570 The symmetric key is encrypted using the merchant's public key 01:16:34.570 --> 01:16:38.370 exchange key, which was retrieved from the certificate that the 01:16:38.370 --> 01:16:41.390 merchant had sent to the payment gateway. 01:16:42.350 --> 01:16:46.950 And then we have this encrypted authorization message here, and the 01:16:46.950 --> 01:16:51.790 digital envelope that corresponds to that allows to actually access... 01:16:51.790 --> 01:16:54.230 if you can open it, you can access the encrypted authorization 01:16:54.230 --> 01:16:54.770 message. 01:16:57.110 --> 01:17:00.130 Now, what else does it provide? 01:17:00.290 --> 01:17:02.130 It provides some capture token. 01:17:03.030 --> 01:17:08.510 Now, the capture token is an information that is necessary for 01:17:08.510 --> 01:17:14.310 actually initiating the transfer of money from the account of the 01:17:14.310 --> 01:17:16.230 cardholder to the account of the merchant. 01:17:17.170 --> 01:17:22.490 Now, this can only be used after the purchase has been completed. 01:17:22.490 --> 01:17:30.410 So, at this point, there was only this request, whether actually the 01:17:30.410 --> 01:17:33.370 cardholder is good for that amount. 01:17:34.190 --> 01:17:42.110 And so the cardholder's bank just has noticed, okay, there has been 01:17:42.110 --> 01:17:42.830 this request. 01:17:43.250 --> 01:17:48.750 This is certainly memorized there at the bank, it's stored. 01:17:48.750 --> 01:17:50.810 And you get a capture token. 01:17:51.990 --> 01:17:57.310 Whoever has this capture token can get this amount of money. 01:17:57.910 --> 01:18:02.030 This is sent to the merchant in an encrypted form. 01:18:02.410 --> 01:18:07.250 So, it is encrypted using, again, a session key. 01:18:07.710 --> 01:18:14.510 And this session key is encrypted using the payment gateway's public 01:18:14.510 --> 01:18:15.610 key exchange key. 01:18:15.610 --> 01:18:20.790 So, the payment gateway sends a session key and encrypts the session 01:18:20.790 --> 01:18:25.830 key with its own public key for the key exchange. 01:18:26.450 --> 01:18:31.570 That means the merchant will not be able to decrypt this message. 01:18:32.030 --> 01:18:35.390 Only the payment gateway will be able to decrypt this message. 01:18:35.870 --> 01:18:42.170 So, this is secret information that is sent to the merchant. 01:18:42.170 --> 01:18:48.590 It is a capture token in a digital envelope, which can only be opened 01:18:48.590 --> 01:18:49.830 by the payment gateway. 01:18:49.970 --> 01:18:52.530 It cannot be opened by the merchant. 01:18:53.270 --> 01:19:03.350 So, whenever the merchant wants to actually retrieve the money, he has 01:19:03.350 --> 01:19:07.870 to send this information back to the payment gateway. 01:19:07.870 --> 01:19:11.150 And then this will reprocess and he will actually get his money. 01:19:11.310 --> 01:19:14.830 But only at a later time, after the transaction with the cardholder 01:19:14.830 --> 01:19:15.750 has been completed. 01:19:17.090 --> 01:19:20.670 The merchant gets the necessary information that he requested in his 01:19:20.670 --> 01:19:22.630 encrypted authorization message. 01:19:22.910 --> 01:19:28.850 And this can be accessed by him using the digital envelope that can be 01:19:28.850 --> 01:19:32.250 opened by his key exchange. 01:19:33.150 --> 01:19:34.930 So, this is sent to the merchant. 01:19:34.930 --> 01:19:38.850 The merchant gets this information, decrypts the authorization 01:19:38.850 --> 01:19:44.910 message, and checks the integrity, and then the transaction with the 01:19:44.910 --> 01:19:45.890 customer can proceed. 01:19:47.010 --> 01:19:50.490 And at a later time, the payment capture occurs. 01:19:50.710 --> 01:19:54.590 So, at this point, the merchant requests the payment, sends this 01:19:54.590 --> 01:19:55.450 capture request. 01:19:56.030 --> 01:20:00.930 The payment gateway can open the payment request and send a capture 01:20:00.930 --> 01:20:04.950 response, such that the merchant knows the money has been transferred. 01:20:05.430 --> 01:20:07.130 Now, how is this actually compiled? 01:20:07.850 --> 01:20:15.390 The original capture request, again, is secured with a digital 01:20:15.390 --> 01:20:19.370 signature, so you get here another digital signature on this capture 01:20:19.370 --> 01:20:19.950 request. 01:20:21.790 --> 01:20:23.970 This is the capture request by the merchant. 01:20:24.790 --> 01:20:28.370 This is plain text, containing some information. 01:20:30.990 --> 01:20:35.970 And, which is not really that much of interest at the moment. 01:20:36.490 --> 01:20:39.910 This is encrypted, again, using a session key. 01:20:40.350 --> 01:20:43.970 The session key is encrypted using the payment gateway's public key 01:20:43.970 --> 01:20:44.690 exchange key. 01:20:45.330 --> 01:20:52.390 And, as said, the capture request has to be, has to contain also the 01:20:52.390 --> 01:20:53.730 token message. 01:20:53.730 --> 01:20:58.050 This is a token message, a capture token message, that you receive 01:20:58.050 --> 01:20:59.870 from the payment gateway. 01:21:00.510 --> 01:21:03.310 And he has to send this back to the payment gateway. 01:21:04.150 --> 01:21:11.170 And now the payment gateway can decrypt the encrypted capture request 01:21:11.170 --> 01:21:13.950 message that was set up by the merchant. 01:21:14.910 --> 01:21:20.850 The bank can open it, because it has the private key available for 01:21:20.850 --> 01:21:22.990 opening the digital envelope. 01:21:22.990 --> 01:21:29.910 And the payment gateway can also open this capture token message, 01:21:30.270 --> 01:21:35.970 because it has also its private key for the key exchange. 01:21:36.670 --> 01:21:48.130 And now this is all used to actually provide all the information to 01:21:48.130 --> 01:21:50.810 the payment gateway that it needs to transfer the money. 01:21:51.700 --> 01:21:57.510 And so the capture request and the capture token is, or this 01:21:57.510 --> 01:22:01.250 information is sent to the cardholder financial institution using 01:22:01.250 --> 01:22:04.670 another appropriate protocol, which is not of interest to us at the 01:22:04.670 --> 01:22:04.950 moment. 01:22:05.630 --> 01:22:11.750 This transaction is done, and the payment gateway responds to the 01:22:11.750 --> 01:22:16.710 merchant with some capture response message. 01:22:16.710 --> 01:22:29.570 And it is, again, so the merchant can decrypt all this and gets the 01:22:29.570 --> 01:22:35.970 information from the payment gateway that everything has been 01:22:35.970 --> 01:22:40.910 transferred correctly, the funds are at the merchant's place. 01:22:40.910 --> 01:22:47.910 Now this was a complicated protocol, complicated because there were 01:22:47.910 --> 01:22:53.050 several places where we used this secure communication protocol that I 01:22:53.050 --> 01:22:55.570 had presented to you already before. 01:22:56.510 --> 01:23:01.230 The major point is that we have a dual signature, which combines 01:23:01.230 --> 01:23:04.730 private and obvious payment information and the ordering information. 01:23:04.730 --> 01:23:08.850 And this dual signature provides a much higher degree of anonymity for 01:23:08.850 --> 01:23:13.650 credit card transactions than we have in normal credit card 01:23:13.650 --> 01:23:13.990 transactions. 01:23:14.470 --> 01:23:19.210 Usually we don't have anything like that in credit card transactions. 01:23:20.770 --> 01:23:25.510 And, well, we have two separate public key pairs, provides additional 01:23:25.510 --> 01:23:33.490 security, and certainly resides in additional overhead, but this is 01:23:33.490 --> 01:23:36.050 just taken into account here. 01:23:36.670 --> 01:23:40.590 So we have public key pairs for exchanging session keys and for 01:23:40.590 --> 01:23:46.430 digital signatures, and this then uses just the standard secure 01:23:46.430 --> 01:23:49.130 protocol communication as I presented to you before. 01:23:50.190 --> 01:23:54.750 And then we have another point that is important, this CAPTCHA token, 01:23:54.990 --> 01:24:01.210 which is compiled by the payment gateway, sent to the merchant, but 01:24:01.210 --> 01:24:04.130 the merchant cannot do anything with it, cannot access it, it has to 01:24:04.130 --> 01:24:10.130 be returned to the payment gateway, which can then open it again and 01:24:10.130 --> 01:24:14.050 initiate the actual transfer of money. 01:24:15.070 --> 01:24:18.570 That's SET, providing quite a level of security. 01:24:19.410 --> 01:24:24.510 The problem is that SET is quite expensive, so the transaction costs 01:24:24.510 --> 01:24:30.890 are too high, or the initial investment is quite high, and therefore 01:24:30.890 --> 01:24:35.470 SET has been designed by these companies, but in order to use it on 01:24:35.470 --> 01:24:40.270 your computer, you have to invest, the merchant has to invest some 01:24:40.270 --> 01:24:44.670 money, and so it's only used in very few places. 01:24:45.330 --> 01:24:49.070 It's another point that technology is available, algorithms are 01:24:49.070 --> 01:24:57.210 available to provide good properties that are desirable, but so far 01:24:57.210 --> 01:25:03.370 these algorithms are not really used in practice. 01:25:04.410 --> 01:25:09.110 There's another protocol that is used by a company who provides cyber 01:25:09.110 --> 01:25:09.670 cash. 01:25:10.950 --> 01:25:15.610 We can... I can just briefly check whether that actually works. 01:25:16.030 --> 01:25:19.150 Sometimes the problems do that. 01:25:20.650 --> 01:25:27.130 Last night, I checked that, I re-established the link in here, it 01:25:27.130 --> 01:25:33.650 worked, completely correct, and now it doesn't know how to open the 01:25:33.650 --> 01:25:40.170 file that I have here, but I have prepared for that, I can just go, 01:25:40.590 --> 01:25:41.730 exactly, here it is. 01:25:42.310 --> 01:25:48.190 There's our demo, six steps to this cyber cash, so this is an 01:25:48.190 --> 01:25:50.430 animation of what cyber cash is doing. 01:25:50.870 --> 01:25:55.530 Here we have the situation that a consumer is shopping for flowers 01:25:55.530 --> 01:26:04.470 over the internet, and the consumer is selecting flowers, he has to 01:26:04.470 --> 01:26:09.570 enter shipping and credit card information, so this is, here we have a 01:26:09.570 --> 01:26:13.170 combination of payment information and ordering information in one 01:26:13.170 --> 01:26:16.790 document, we don't have this separation into ordering information and 01:26:16.790 --> 01:26:18.430 payment information as with SCT. 01:26:19.410 --> 01:26:25.230 Then, next point is that this actually, or the customer is presented 01:26:25.230 --> 01:26:29.810 with a summary of what he has actually entered there, he has to check 01:26:29.810 --> 01:26:41.910 that this is correct, and so this then is sent using SSL, so here SSL 01:26:41.910 --> 01:26:47.570 is used as a means of getting secure communication for the merchants, 01:26:47.810 --> 01:26:53.490 SSL enabled web server, and the order is passed to the storefront 01:26:53.490 --> 01:27:02.610 software, and the cyber flower shop is then processing it, so you see 01:27:02.610 --> 01:27:08.090 the software passes the payment information to the merchant connection 01:27:08.090 --> 01:27:14.610 kit, a certain piece of software, which runs on the same server, this 01:27:14.610 --> 01:27:20.450 encrypts the transaction with private DES using standard encryption 01:27:20.450 --> 01:27:33.110 strength, and now this is sent to the cyber cache server, so the 01:27:33.110 --> 01:27:38.410 encrypted payment request is sent over the internet, here was the 01:27:38.410 --> 01:27:44.670 secure firewall, which is securing the cyber cache server, it passes 01:27:44.670 --> 01:27:50.210 that firewall, gets to the cyber cache server, and then the cyber 01:27:50.210 --> 01:27:54.030 cache server will check whether everything is correct, so the 01:27:54.030 --> 01:28:00.630 merchant's financial institution will now check with the consumer's 01:28:00.630 --> 01:28:03.510 credit card bank or financial institution whether everything is 01:28:03.510 --> 01:28:07.770 correct, so the cyber cache instantaneously passes the payment request 01:28:07.770 --> 01:28:13.490 to the merchant's financial institution, and then these institutions 01:28:13.490 --> 01:28:20.350 can check whether everything is okay, the information is sent to, or 01:28:20.350 --> 01:28:24.690 this request is sent to the consumer's credit card bank, this 01:28:24.690 --> 01:28:29.990 consumer's bank will say whether the customer is good or not, in this 01:28:29.990 --> 01:28:38.090 case it's good for the money, and then the response is returned to the 01:28:38.090 --> 01:28:44.090 cyber cache service provider, the cyber cache then compiles the 01:28:44.090 --> 01:28:52.210 response message and sends that back to the cyber shop, so then the 01:28:52.210 --> 01:28:57.550 cyber shop will send information to the customer approving that 01:28:57.550 --> 01:29:04.470 transaction, and the next step, the flowers actually are delivered to 01:29:04.470 --> 01:29:10.870 the customer's place, and if that is done, the merchant requests the 01:29:10.870 --> 01:29:14.830 financial settlement or capture of the money, in a similar way as I 01:29:14.830 --> 01:29:22.170 have shown with SET, so the initial starting balance here of the cyber 01:29:22.170 --> 01:29:28.570 flower shop is here $100, then this is processed, money is deposited 01:29:28.570 --> 01:29:38.930 into the account of the merchant, and so you get the next value there 01:29:38.930 --> 01:29:39.550 on that account. 01:29:39.550 --> 01:29:45.910 So the merchant gets its money, the customer has the flowers, and all 01:29:45.910 --> 01:29:49.210 this certainly takes very little time, or should take very little 01:29:49.210 --> 01:29:53.890 time, but you have seen it's not the level of security that we have 01:29:53.890 --> 01:29:58.730 with SET, here just standard decryption methods are used, the payment 01:29:58.730 --> 01:30:02.870 and ordering information is not separated, so we don't have the level 01:30:02.870 --> 01:30:05.030 of anonymity that we have with SET. 01:30:06.750 --> 01:30:13.470 Okay, that is the CyberCache, cache-requisited payment service, which 01:30:13.470 --> 01:30:15.370 can be used at some places. 01:30:16.270 --> 01:30:25.510 Okay, that is the CyberCache system, and just to briefly sum up or 01:30:25.510 --> 01:30:30.810 summarize what that is using, no, so this is eCache, the next thing, 01:30:30.930 --> 01:30:34.810 so this was just CyberCache, here is a summary of CyberCache with a 01:30:34.810 --> 01:30:41.110 few statements on it, so we have these transactions as we just saw in 01:30:41.110 --> 01:30:48.770 this animation, and what is listed here shows that even the use of 01:30:48.770 --> 01:30:54.290 digital signatures does not really provide the same level of security 01:30:54.290 --> 01:31:01.630 as the SET system does, so this is one method that could be used to 01:31:01.630 --> 01:31:05.830 provide some level of security, but not the anonymity, payment and 01:31:05.830 --> 01:31:07.870 ordering information is still disconnected. 01:31:08.490 --> 01:31:14.730 Okay, so next week we will look at eCache, then learn something about 01:31:14.730 --> 01:31:16.330 real electronic money. 01:31:17.070 --> 01:31:21.870 Okay, there was a lot of slides today, 40 slides, I'm amazed that I 01:31:21.870 --> 01:31:25.150 managed to present to you so many slides, maybe it was too much, I 01:31:25.150 --> 01:31:30.850 hope it was not, and we will come back with eCache next week, and 01:31:30.850 --> 01:31:35.230 after that we will look at the next chapter on firewalls. 01:31:35.410 --> 01:31:37.390 Thanks for today, see you again next week.