WEBVTT 00:01.270 --> 00:07.120 So, welcome back to our course on Algorithms for Edited Applications. 00:08.760 --> 00:16.740 Last week you got a hybrid lecture, or you got the recorded lecture of 00:16.740 --> 00:21.240 last year, and it was on RhinDAR. 00:21.380 --> 00:29.320 So, two weeks ago I started to present to you the AES algorithm, and 00:29.320 --> 00:36.820 we had looked there briefly at the general structure. 00:37.240 --> 00:41.280 I had started to tell you something about byte substitution, and then 00:41.280 --> 00:47.620 you were presented more things, the other steps of that round, the 00:47.620 --> 00:56.340 different operations there, and then after that you got some 00:56.340 --> 01:02.140 information on modes of operation for block-wise, for block ciphers, 01:02.360 --> 01:06.980 showing that it's important to actually have more diffusion operations 01:06.980 --> 01:12.380 in addition to the diffusion within a block, the diffusion between 01:12.380 --> 01:18.620 blocks by just combining the information from one block with the 01:18.620 --> 01:19.920 information from the next block. 01:19.920 --> 01:22.380 There were several modes of operation presented to you. 01:22.480 --> 01:28.320 The simple one, the electronic codebook mode, then those that actually 01:28.320 --> 01:33.000 really combine different blocks, the cipher block chaining mode, the 01:33.000 --> 01:37.740 cipher feedback mode, and finally the output feedback mode, all 01:37.740 --> 01:45.500 combining the information of several blocks, and in this way achieving 01:45.500 --> 01:50.460 that the ciphertext that is generated depends actually on what has 01:50.460 --> 01:54.540 been encrypted in the preceding blocks. 01:55.180 --> 01:58.520 The problem there is certainly to look at how we can actually encrypt 01:58.520 --> 02:04.460 and decrypt, to which extent we can do something independent of the 02:04.460 --> 02:11.040 other blocks that have been encrypted there, and that was one part of 02:11.040 --> 02:12.280 the topic of last week. 02:12.800 --> 02:16.380 Then the topic was message digests and digital signatures. 02:16.380 --> 02:24.640 The idea of the digital signature was presented, and then like the one 02:24.640 --> 02:30.740 part there is the one-way hash function that actually provides a hash 02:30.740 --> 02:38.160 value or a message digest which has important information about the 02:38.160 --> 02:40.400 contents of a longer message. 02:41.080 --> 02:46.840 And so there was a remark on the secure hash algorithm that actually 02:46.840 --> 02:51.480 has been extended or has been accepted. 02:51.700 --> 02:57.420 Meanwhile, to some degree, there's one problem with taking a recorded 02:57.420 --> 03:09.740 lecture in the slides that I had already uploaded to the course's 03:09.740 --> 03:10.220 website. 03:10.540 --> 03:14.160 There was an updated version of what you see here now. 03:15.100 --> 03:23.280 So in the recorded lecture that you got last week, there was the same 03:23.280 --> 03:29.160 things as last year, but certain things have been extended, so the 03:29.160 --> 03:36.380 slides that you got from the website or the course actually are a 03:36.380 --> 03:42.200 little bit more up-to-date, because meanwhile they have a winner of 03:42.200 --> 03:47.540 that secure hash algorithm competition, but they are still discussing 03:47.540 --> 03:52.760 on how to actually provide that, and I have given a little bit more 03:52.760 --> 03:56.200 information on that, but the website that is given here is exactly 03:56.200 --> 03:59.240 relevant for that competition. 04:00.120 --> 04:07.360 Then the digital signature was presented, an important aspect that we 04:07.360 --> 04:13.540 can actually get a hash and then sign that hash with a private key, 04:14.120 --> 04:20.620 and in this way have a way of connecting the content of a message with 04:20.620 --> 04:25.800 a person, with an individual, or you could say connected with the 04:25.800 --> 04:32.200 private key, and in this way have a way of authenticating a document. 04:32.880 --> 04:34.080 So that was the idea. 04:34.240 --> 04:40.360 Then we had the man-in-the-middle attack briefly, which shows how one 04:40.360 --> 04:48.640 could actually interfere if there is no concrete knowledge about the 04:48.640 --> 04:50.480 public key that is used. 04:50.560 --> 04:55.660 So if somebody interferes, as shown in this diagram, then the 04:55.660 --> 05:00.680 communication could be disturbed, and there are several ways of 05:00.680 --> 05:03.420 actually doing something against such man-in-the-middle attacks. 05:03.580 --> 05:07.860 One way of doing that is to have a certification of all the public 05:07.860 --> 05:13.360 keys, and if you have certificates and a good public key 05:13.360 --> 05:24.320 infrastructure with certificates for the public keys, then such a man 05:24.320 --> 05:26.880 -in -the-middle attack can be prevented. 05:28.120 --> 05:30.220 There are a few more slides on that. 05:30.220 --> 05:38.240 And finally, there was the application of all these different 05:38.240 --> 05:44.200 cryptographic algorithms for the final communication protocol where 05:44.200 --> 05:50.060 Alice and Bob can communicate by using a combination of asymmetric and 05:50.060 --> 05:56.720 symmetric cryptographic algorithms, encrypting a message using a 05:56.720 --> 06:02.880 random session key, encrypt the random session key using the public 06:02.880 --> 06:07.240 key of the recipient, which certainly has to be certified. 06:08.000 --> 06:13.780 And before encryption, you just sign that document so you have a way 06:13.780 --> 06:16.140 of checking the integrity after decryption. 06:16.740 --> 06:21.900 So the encrypted key, the encrypted message, and the signature is sent 06:21.900 --> 06:29.020 to the recipient, Bob, who can then decrypt the session key by using 06:29.020 --> 06:34.160 the private key, use the session key to decrypt the message, check or 06:34.160 --> 06:39.720 derive a message digest, decrypt the message digest that had been sent 06:39.720 --> 06:45.880 in the digital signature, and then check whether they both coincide in 06:45.880 --> 06:48.140 this way, check the integrity of the document. 06:48.140 --> 06:51.330 So you have authentication and integrity check and confidentiality 06:51.660 --> 06:53.260 because of the encrypted document. 06:53.420 --> 07:01.040 So this is a way which ensures secure communication between 07:01.040 --> 07:02.380 communication partners. 07:03.100 --> 07:10.820 That was the final slide of last week, and then we can come to the new 07:10.820 --> 07:14.240 chapter on payment systems. 07:16.380 --> 07:23.540 Some of you look a little bit like with question marks in your eyes. 07:23.920 --> 07:26.240 So anything that is not clear? 07:27.360 --> 07:28.320 Okay, good. 07:28.820 --> 07:33.220 So now this week, we should look at electronic payment systems. 07:33.540 --> 07:38.580 And yesterday, last night, I uploaded the slides for this chapter. 07:38.580 --> 07:45.040 So I assume that you did not really have a chance to download those 07:45.040 --> 07:47.580 slides, but they are available. 07:48.800 --> 07:56.800 And I updated this chapter a little bit compared to last year because 07:56.800 --> 07:59.620 I included a little bit more than last year. 08:00.660 --> 08:04.180 So what is this about, this chapter? 08:04.340 --> 08:05.840 Electronic payment systems. 08:05.840 --> 08:12.200 We certainly have many different ways of applying cryptographic 08:12.200 --> 08:16.160 algorithms, and you have a question with respect to this chapter. 08:20.350 --> 08:22.050 No, certainly not. 08:22.170 --> 08:28.550 The exam on Thursday, like the bonus exam, will be just related to 08:28.550 --> 08:32.170 things that we looked at up to the end of last year. 08:32.950 --> 08:33.350 Yeah? 08:33.850 --> 08:37.570 So it will not be on payment systems, definitely not. 08:39.230 --> 08:44.990 So there may be, or could be, some things in there on cryptographic 08:44.990 --> 08:49.070 algorithms because we presented those things in December. 08:49.890 --> 08:55.570 But in the tutorials, you didn't really have an assignment which was 08:55.570 --> 09:00.830 completed on cryptographic algorithms, so the emphasis is more on the 09:00.830 --> 09:02.010 parts before that. 09:02.990 --> 09:07.410 So the idea, because the idea is to see to what extent you have 09:07.410 --> 09:13.390 successfully worked on the exercises, on the assignments, and those 09:13.390 --> 09:17.570 who have done that successfully have a bonus in this bonus exam. 09:18.110 --> 09:25.890 This bonus exam is a replacement of having, of actually checking or 09:25.890 --> 09:32.430 giving you a way of submitting assignments and then collect points in 09:32.430 --> 09:36.290 these assignments because we noticed that it's sometimes difficult to 09:36.290 --> 09:41.810 actually find out who has actually worked on certain assignments and 09:41.810 --> 09:46.230 this bonus exam seems to be a good idea. 09:46.450 --> 09:51.990 Bonus exam is not an exam which is completely, or which is some kind 09:51.990 --> 09:53.690 of test exam for the final exam. 09:53.690 --> 09:58.050 It is quite a bit related to things that had been done in the 09:58.050 --> 10:00.990 assignments in this course so far. 10:02.270 --> 10:06.530 And so, but good that you make a remark on that. 10:06.670 --> 10:12.970 So the bonus exam is this Thursday and then certainly there will be 10:12.970 --> 10:14.990 the final exam at the end of the course. 10:15.630 --> 10:22.050 The registration period started for the final exam, so you should also 10:22.050 --> 10:23.530 register for the final exam. 10:24.230 --> 10:27.690 If you want to take it at the end of this term, which I assume that 10:27.690 --> 10:29.510 most of you will take it at the end of this term. 10:30.030 --> 10:34.910 Certainly we also offer the exam at the end of next term, but that's 10:34.910 --> 10:39.290 like the normal thing would be to have to take the exam now. 10:39.910 --> 10:43.870 Okay, let's come back to the electronic payment system. 10:44.090 --> 10:48.330 So this is the typical application of cryptographic algorithms because 10:48.330 --> 10:50.230 payments have to be done in a secure way. 10:50.230 --> 10:53.070 And you would see how we would actually do that. 10:53.190 --> 10:55.750 So there are different systems that are available. 10:56.450 --> 10:59.930 The simple system is to use just other payment systems, like, for 10:59.930 --> 11:01.050 example, credit cards. 11:01.130 --> 11:03.350 And there are different ways of actually doing that. 11:04.510 --> 11:10.490 SSL, TLS is not really a payment method, but it is a secure way of 11:10.490 --> 11:11.130 communication. 11:11.670 --> 11:13.310 I will make a few statements on that. 11:13.650 --> 11:17.830 Then there's specific protocol for supporting payment with credit 11:17.830 --> 11:18.270 cards. 11:18.270 --> 11:21.950 And there are certain payment service systems, and actually there is 11:21.950 --> 11:23.730 also true electronic money. 11:24.510 --> 11:27.030 Pre-payment systems were like cash. 11:27.330 --> 11:31.630 You deduct some money from your account, and then you get something in 11:31.630 --> 11:35.290 your hand or in your wallet which you can use and claim that as money. 11:36.010 --> 11:37.650 And you can exchange that freely. 11:37.870 --> 11:41.270 The question is whether we can actually generate that in electronic 11:41.270 --> 11:44.690 form, which is equivalent to having electronic cash. 11:44.850 --> 11:47.850 And there have been several concepts for that. 11:47.850 --> 11:52.110 One concept is e-cash or digi-cash. 11:53.650 --> 12:00.670 And one topic or one concept which is quite prominent at the moment is 12:00.670 --> 12:01.210 bitcoins. 12:01.570 --> 12:05.870 So I included a few slides on bitcoins also in this chapter. 12:06.790 --> 12:11.390 And these are different approaches to actually generating electronic 12:11.390 --> 12:11.710 money. 12:11.910 --> 12:15.030 You know that there's quite some discussion going on at the moment on 12:15.030 --> 12:17.210 the relevance of bitcoins. 12:17.730 --> 12:21.770 People thought that it was almost dead, but it seems to be really 12:21.770 --> 12:30.970 becoming a separate currency which has some relevance with respect to 12:30.970 --> 12:35.730 buying some goods on Internet markets. 12:36.690 --> 12:39.750 And there's quite some discussion between different countries whether 12:39.750 --> 12:42.490 they can support that or tolerate that or not. 12:42.490 --> 12:47.130 China was one of the largest bitcoin markets, and now the Chinese 12:47.130 --> 12:51.050 government has done or has restricted that quite significantly. 12:52.010 --> 12:55.610 So there had been quite some discussions on bitcoins, so I thought I 12:55.610 --> 12:59.790 have to include that, at least show a little bit how that works. 12:59.990 --> 13:05.430 And it makes strong use of cryptographic methods. 13:06.430 --> 13:08.970 Then there are smart cards available for paying. 13:09.690 --> 13:12.970 These are the different things that I will present to you in this 13:12.970 --> 13:13.370 chapter. 13:19.130 --> 13:23.770 What kind of things are we talking about when we talk about electronic 13:23.770 --> 13:24.670 payment systems? 13:25.170 --> 13:28.690 Let me just briefly characterize what a payment system actually is. 13:29.250 --> 13:34.110 There are different types of payment systems, so-called two-party 13:34.110 --> 13:38.690 stored value systems, three-party stored value systems, and open loop 13:38.690 --> 13:39.850 stored value systems. 13:40.250 --> 13:44.670 And you know these systems to some extent, so they are all based on 13:44.670 --> 13:45.470 prepayment. 13:45.630 --> 13:50.090 So this is looking at how can I actually create something where I can 13:50.090 --> 13:55.070 pay for something, independent of the credit card things and home 13:55.070 --> 13:55.750 banking things. 13:56.550 --> 13:59.130 So let's look at what we have here. 13:59.230 --> 14:05.530 In the example transfer to a university scenario, you assume that you 14:05.530 --> 14:12.330 get some money on, in this case for example, on your student card, 14:13.230 --> 14:14.930 your identity card for the university. 14:15.530 --> 14:20.910 You give some money to the university and you get back some stored 14:20.910 --> 14:23.290 value on your student card. 14:23.950 --> 14:25.390 You can do something with that. 14:25.750 --> 14:26.910 What can you do with that? 14:27.030 --> 14:31.810 You can use the stored value to buy something within the university, 14:32.750 --> 14:34.830 but not outside of that. 14:35.190 --> 14:37.310 And so for that you get some services. 14:37.730 --> 14:42.850 You can use printing services, copying services, or for example, get 14:42.850 --> 14:44.750 food or things like that. 14:45.330 --> 14:48.730 But you cannot do anything with that outside the university. 14:48.930 --> 14:53.710 So it's a two-party system and you can only use it in your 14:53.710 --> 14:59.250 relationship with the university, not beyond that. 14:59.250 --> 15:01.930 So this is a very simple payment system. 15:02.410 --> 15:08.250 You just have some stored value and you can make partial payments from 15:08.250 --> 15:09.870 that stored value. 15:11.870 --> 15:15.890 Second level is that you have more than those two parties. 15:16.090 --> 15:17.090 You have three parties. 15:17.710 --> 15:22.090 Again, as before, you have the money that you give to the university. 15:22.090 --> 15:31.250 You have the stored value that you get back from the university on 15:31.250 --> 15:32.250 your identity card. 15:33.150 --> 15:35.790 And then you can go to some other shops. 15:36.630 --> 15:39.010 That would be the third party involved there. 15:39.130 --> 15:39.890 Some other shop. 15:40.010 --> 15:41.710 And you present that stored value. 15:42.330 --> 15:48.450 Now, how does that shop know that this stored value actually is valid? 15:49.410 --> 15:51.330 Maybe you have generated that on your own. 15:51.330 --> 15:55.510 You have to check in some way that that is actual value. 15:56.090 --> 16:03.110 You could get some services, but then the shop actually has to 16:03.110 --> 16:04.750 retrieve the money in some way. 16:04.830 --> 16:11.210 Because you have given money to the university and you now just give 16:11.210 --> 16:12.610 the stored value to the shop. 16:12.610 --> 16:16.590 So the shop must have a way of retrieving the money using the 16:16.590 --> 16:21.910 information that you transmitted using your card to that shop. 16:22.130 --> 16:27.170 So the shop will present that stored value in some way to the 16:27.170 --> 16:29.510 university and get money back. 16:32.450 --> 16:38.230 So this mechanism has to be supported in appropriate ways by some 16:38.230 --> 16:40.310 electronic transactions. 16:40.310 --> 16:46.870 So this would be a third party or three party system where a shop is 16:46.870 --> 16:51.190 able to actually retrieve the money that has been stored on the 16:51.190 --> 16:51.910 student card. 16:52.350 --> 16:55.730 And you get some of that value that is transferred to the shop. 16:55.870 --> 16:59.350 And then the shop needs a way of actually getting back that money. 17:01.190 --> 17:06.330 So here, certainly you can always transfer that into a real world 17:06.330 --> 17:10.270 scenario where you have not the university and student, but a bank and 17:10.270 --> 17:10.770 a customer. 17:11.890 --> 17:18.470 And what we have, for example, is on the gate card or bank card, the 17:18.470 --> 17:24.510 smart card, you can have some stored value and a shop can accept that 17:24.510 --> 17:25.030 value. 17:25.030 --> 17:30.570 For example, if you use that at the ticket machines for public 17:30.570 --> 17:35.150 transportation, they deduct some money from your card and then get 17:35.150 --> 17:37.270 that money back from the bank. 17:37.890 --> 17:40.330 So this is similar to that system. 17:41.010 --> 17:48.090 And then there is an open loop system and this is actually more like 17:48.090 --> 17:49.430 real cash. 17:49.590 --> 17:54.890 Here, you give money again to the university or customer goes to the 17:54.890 --> 18:00.430 bank, provides some money, gets some stored value back. 18:01.050 --> 18:05.010 And then this stored value is used to buy something at a shop. 18:05.910 --> 18:11.230 And the stored value again can be cashed into real money. 18:12.070 --> 18:17.910 But it could also be used like a shop could present something, some 18:17.910 --> 18:24.930 goods to this other shop and they could now take the stored value that 18:24.930 --> 18:29.350 they got from the student, they could forward that to another 18:29.350 --> 18:30.430 participant there. 18:30.430 --> 18:33.690 So in this case, this would be an open loop system. 18:34.090 --> 18:39.610 You can use that stored value that you got from a student actually to 18:39.610 --> 18:44.590 buy things at another participant of that payment systems. 18:44.770 --> 18:49.550 Or students could work for that shop and get stored value back. 18:50.090 --> 18:53.610 And so this would be an open loop system similar to cash, where you 18:53.610 --> 18:58.430 just hand over cash for getting some service or good. 18:59.410 --> 19:02.310 So this is something which would be an open loop system. 19:02.390 --> 19:04.190 The cash system is an open loop system. 19:06.250 --> 19:11.550 And if you like to, you can just deposit or bring that to the bank and 19:11.550 --> 19:15.950 the value, the corresponding value is then deposited on your account. 19:16.910 --> 19:18.650 And we say that is real money. 19:18.930 --> 19:20.610 It's always a question, what is real money? 19:21.030 --> 19:24.250 Is the real money the money that we have as cash? 19:24.530 --> 19:27.250 Or is the real money the money that is in our account? 19:27.250 --> 19:33.110 Cash is something like prepaid money, that you have prepaid payment 19:33.110 --> 19:39.090 method, where you have some amount deducted from your account and you 19:39.090 --> 19:39.690 get cash. 19:41.290 --> 19:47.250 Okay, so these are the different payment systems that I think are 19:47.250 --> 19:47.930 relevant. 19:48.790 --> 19:53.250 And students could also get services from other students, pay back 19:53.250 --> 19:54.870 those stored values. 19:54.870 --> 20:00.530 So this would be a freely exchangeable currency like cash. 20:00.630 --> 20:05.530 And this is very hard to actually implement, because assume you have a 20:05.530 --> 20:10.630 stored value, the typical problem that you have to cope with is that 20:10.630 --> 20:16.490 if you have some electronic entity of your computer or in your 20:16.490 --> 20:20.170 electronic wallet, it's very simple to make a copy of that. 20:20.850 --> 20:26.950 You just copy the file containing the information and how can you 20:26.950 --> 20:31.990 check that this copy is... 20:31.990 --> 20:37.650 this is not just something how you can really increase your wealth by 20:37.650 --> 20:42.450 just copying money, but that there is some value behind that. 20:42.950 --> 20:47.370 So double spending is the typical problem that you have to look at. 20:47.370 --> 21:04.350 So, certainly, as soon as you have exchanged the stored value for real 21:04.350 --> 21:09.170 money, you cannot do that twice with the stored value that you 21:09.170 --> 21:09.650 presented. 21:09.810 --> 21:11.030 You can only do that once. 21:11.030 --> 21:17.530 You have to check that there's no double spending possible or that 21:17.530 --> 21:19.130 double spending will be detected. 21:20.750 --> 21:28.310 If you pay with real cash, you cannot easily copy cash. 21:28.970 --> 21:35.110 You could try to copy paper money, but you know that that's illegal. 21:35.110 --> 21:40.510 So, how can you make sure, how can you detect false money, false cash, 21:40.850 --> 21:44.690 copied money in electronic form? 21:44.790 --> 21:47.530 That is the problem that we have to look at. 21:47.670 --> 21:52.870 Double spending has to be prevented and that's the major problem with 21:52.870 --> 21:54.330 respect to open loop systems. 21:55.330 --> 21:59.670 Normally, we have something which is just the first or second level in 21:59.670 --> 22:05.630 electronic payment system or electronic cash, unless we go to systems 22:05.630 --> 22:09.850 where we just use other payment methods and support those payment 22:09.850 --> 22:14.890 methods with electronic means, which we will look at in a moment. 22:15.530 --> 22:19.190 If we have electronic payment systems, what are actually the criteria 22:19.190 --> 22:23.170 that we use for evaluating the quality of those systems? 22:23.170 --> 22:28.870 So, certainly one would be system security, reliability, safety with 22:28.870 --> 22:30.990 respect to, for example, double spending. 22:31.550 --> 22:38.170 Then, what does it actually cost to have electronic transactions with 22:38.170 --> 22:38.570 money? 22:39.550 --> 22:44.650 It doesn't cost anything to transfer cash, but what does it cost to 22:44.650 --> 22:49.090 process electronic payment transactions? 22:50.550 --> 22:52.130 Then, traceability. 22:53.250 --> 22:57.790 With cash, you can just hand it over to somebody else and you don't 22:57.790 --> 23:02.390 notice from the cash that you look at, oh, this coin has been owned by 23:02.390 --> 23:03.330 that person. 23:03.770 --> 23:05.110 You don't see that. 23:06.910 --> 23:09.530 You see that if you pay by credit card. 23:09.690 --> 23:15.610 You know exactly what has been paid where and when, by whom. 23:16.890 --> 23:24.210 But for normal payments, like using cash, there's no traceability. 23:24.970 --> 23:26.750 And certainly also no accountability. 23:27.890 --> 23:34.910 And this is also something which is a danger that is seen by those who 23:34.910 --> 23:43.310 control currencies, like money washing is something which is an 23:43.310 --> 23:51.530 important problem that you would like to just wash black money into 23:51.530 --> 23:52.650 better money. 23:53.050 --> 23:57.890 If you have some sources of money, people and some people have an 23:57.890 --> 24:01.690 interest of actually getting that safely on their bank account. 24:02.490 --> 24:08.130 And if you have electronic forms of money, you have to make sure that 24:08.130 --> 24:11.290 there's some traceability concerned with the money. 24:11.390 --> 24:13.130 Where does that money actually come from? 24:13.750 --> 24:18.050 And so this is something which is an important topic for those who 24:18.050 --> 24:23.090 look at currencies in one or the other way. 24:24.950 --> 24:28.830 But certainly we would like to have, as customers, we would like to 24:28.830 --> 24:30.970 have anonymity for payment events. 24:32.330 --> 24:37.190 Those who get the money or those who control currencies don't like 24:37.190 --> 24:37.810 anonymity. 24:38.130 --> 24:40.070 But we as customers like anonymity. 24:40.870 --> 24:44.170 This is something which has to be... there's a trade-off. 24:44.170 --> 24:49.890 Then the question is, to which extent do I have to check online 24:49.890 --> 24:53.210 whether a payment event is valid? 24:55.030 --> 25:01.390 And what does it mean for what I can do afterwards with the units of 25:01.390 --> 25:03.250 money that I actually got? 25:04.330 --> 25:07.550 Acceptability, who will actually accept such forms of payment? 25:08.110 --> 25:09.510 What about transferability? 25:09.510 --> 25:13.470 In a city, if a beggar is on the street, you can give some money to a 25:13.470 --> 25:13.790 beggar. 25:15.070 --> 25:21.090 But if you have only your credit card or bank card, you cannot give 25:21.090 --> 25:21.490 anything. 25:22.150 --> 25:25.850 You cannot transfer money from one person to the other easily if you 25:25.850 --> 25:29.170 have your money just on your smart card. 25:30.490 --> 25:36.270 In Norway, they are talking about getting rid of cash. 25:37.130 --> 25:40.970 Only have smart cards, electronic forms of payment. 25:42.910 --> 25:44.030 Is that acceptable? 25:44.470 --> 25:45.130 I don't know. 25:45.710 --> 25:49.590 We need transferability to some extent between persons. 25:50.310 --> 25:55.690 If you can only transfer money by involving some institution behind, 25:56.590 --> 25:57.730 do we really want that? 25:57.990 --> 25:59.350 It's a difficult problem. 26:00.350 --> 26:04.230 Divisibility, we would like to be able to pay any amount, even 26:04.230 --> 26:09.710 micropayments of 0.something cents for certain transactions. 26:11.350 --> 26:15.750 Like transactions, if we are using something in the internet, we have 26:15.750 --> 26:16.710 to pay for that. 26:16.990 --> 26:20.310 Micropayments are very important because you don't want to pay several 26:20.310 --> 26:23.730 cents for something, but micropayments, just a fraction of a cent. 26:23.730 --> 26:30.170 If you have many of those transactions, it sums up to some value, but 26:30.170 --> 26:34.070 normally you only have micropayments there and you need divisibility 26:34.070 --> 26:34.590 for that. 26:35.610 --> 26:38.790 I will go more into details for those things. 26:38.950 --> 26:40.610 You know something about system security. 26:41.450 --> 26:48.310 I would like to protect communication channels if I pay by credit card 26:48.310 --> 26:50.630 or make some payment in some way. 26:50.630 --> 26:56.290 Usually I use HTTPS, so use secure channels for that. 26:56.850 --> 26:58.150 How can we get that? 26:58.690 --> 27:02.650 So I would like to use cryptographic protocols for secure transmission 27:02.650 --> 27:03.310 communication. 27:04.050 --> 27:11.030 The banking system, there is a special network for electronic fund 27:11.030 --> 27:16.250 transfer, which is separated from the normal internet of data. 27:17.250 --> 27:23.190 But the SWIFT network has been designed many years ago for electronic 27:23.190 --> 27:23.910 fund transfer. 27:24.210 --> 27:28.210 Meanwhile, everything is running over the internet and we use 27:28.210 --> 27:29.710 cryptographic protocols for that. 27:30.310 --> 27:34.850 We know all kinds of authentication and identity checks for payments. 27:35.030 --> 27:41.290 We have PIN numbers, we have tons, I did not mention it here, but we 27:41.290 --> 27:47.190 have the transaction numbers which have to be generated appropriately, 27:47.810 --> 27:50.710 provided for payment. 27:52.310 --> 27:56.930 We have password, passphrase systems, digital signatures, all kinds of 27:56.930 --> 28:00.110 intelligent chip cards, so authentication is important. 28:00.850 --> 28:03.570 And there are some mechanisms for hardware protection. 28:03.970 --> 28:09.450 We have some chip cards which provide some extra protection methods. 28:09.450 --> 28:10.290 You have another question? 28:15.000 --> 28:15.400 Yes. 28:25.130 --> 28:29.870 Okay, the question was for those who just listened to the recorded 28:29.870 --> 28:35.570 lecture and to which extent the discussion on transaction numbers and 28:35.570 --> 28:39.390 the validity and security of transaction numbers is relevant. 28:39.890 --> 28:46.950 So there has been some discussion that it's not really secure anymore 28:46.950 --> 28:53.210 to use tons sent to you by an SMS message, things like that. 28:54.690 --> 29:02.990 The question is to what extent such a ton that is eavesdropped by some 29:02.990 --> 29:10.270 enemy or some other party can be used for false transactions, can be 29:10.270 --> 29:10.890 misused. 29:12.130 --> 29:13.830 This is an important topic. 29:14.610 --> 29:20.330 So if you have a transaction number, you can actually use that 29:20.330 --> 29:22.970 transaction number for some payment event. 29:24.110 --> 29:29.270 What I don't see really is, normally a transaction number is 29:29.270 --> 29:34.450 associated with an individual payment event. 29:34.690 --> 29:37.250 First of all, you specify the payment event. 29:37.250 --> 29:43.910 So if I, for example, generate a ton for online banking, I specify the 29:43.910 --> 29:49.170 amount that has to be paid, I specify the account to which something 29:49.170 --> 29:54.330 has to be sent, and there's at least those two things. 29:55.570 --> 30:00.950 And then I generate a transaction number automatically, not with an 30:00.950 --> 30:06.890 SMS, but usually I use these devices that you just put in front of 30:06.890 --> 30:10.290 your screen, and you can do the optical communication. 30:10.790 --> 30:13.970 You probably know these devices where you can generate your ton 30:13.970 --> 30:14.810 electronically. 30:15.230 --> 30:17.770 That cannot be really misused. 30:17.990 --> 30:25.250 If you get the ton by an SMS message, even for that, if the ton is 30:25.250 --> 30:31.970 generated just for this event, then you cannot misuse that, because it 30:31.970 --> 30:37.330 is connected with exactly that information, specific account, specific 30:37.330 --> 30:39.090 amount that has to be transferred. 30:39.870 --> 30:44.670 But if the transaction number is just like it used to be, that you had 30:44.670 --> 30:49.370 a piece of paper, and there you had a listing of all the tons, and you 30:49.370 --> 30:52.370 just could use them in a specific sequence. 30:52.970 --> 30:56.710 You had a transaction number which could be used for the next event 30:56.710 --> 30:59.070 that you would like to sign. 30:59.790 --> 31:04.970 But if the transaction number is associated with a specific account, 31:05.770 --> 31:10.770 and specific amount, and a date where it has to be, like individual 31:10.770 --> 31:13.550 information, then I don't see how it can be misused. 31:14.090 --> 31:18.010 But there must be some relevance behind those discussions that are 31:18.010 --> 31:20.350 currently going on in the media. 31:21.310 --> 31:21.910 Yes. 31:30.920 --> 31:31.520 Definitely. 31:32.140 --> 31:32.380 Yes. 31:32.520 --> 31:37.400 If you have a list of tons on a piece of paper, that can be misused by 31:37.400 --> 31:38.000 somebody else. 31:38.100 --> 31:43.160 If somebody gets that, and has your account number, then somebody else 31:43.160 --> 31:47.060 could actually authenticate certain transactions. 31:49.500 --> 31:50.260 Yes. 31:57.920 --> 32:04.440 But if the transaction numbers are just transaction numbers that are, 32:05.620 --> 32:10.120 like, here you have a transaction, or a list of transaction numbers 32:10.120 --> 32:11.760 that are valid transaction numbers. 32:12.160 --> 32:15.820 And these transaction numbers on a piece of paper, that's the old 32:15.820 --> 32:22.160 system, they were generated independent of any explicit payment 32:22.160 --> 32:22.780 transactions. 32:24.340 --> 32:28.960 They were just selected for authenticating a payment. 32:29.780 --> 32:34.040 It was assumed that only you have access to that piece of paper, to 32:34.040 --> 32:38.520 that list of tons, and then only you could actually use them, and they 32:38.520 --> 32:40.100 could only be used once. 32:40.100 --> 32:44.500 You had to cross them out, and then you knew, okay, those have been 32:44.500 --> 32:46.180 used, I can use some of the others. 32:47.240 --> 32:54.100 But, so if the SMS system is just a replacement of such a piece of 32:54.100 --> 33:00.400 paper, sending you tons taken from some pre-generated list of tons, 33:00.700 --> 33:06.760 but not associated with explicit events, so it could be done that you 33:06.760 --> 33:10.680 have your window where you actually specify a certain payment, and 33:10.680 --> 33:16.480 then you ask for a ton, and the system just sends you a valid 33:16.480 --> 33:17.740 transaction number. 33:19.020 --> 33:22.920 But this transaction number can be used for any purpose. 33:24.360 --> 33:26.480 Then it can be misused. 33:26.480 --> 33:33.540 But if the ton is associated with a specific account, then it can not 33:33.540 --> 33:34.540 really be misused. 33:39.890 --> 33:46.570 Well, the problems that are there, if somebody, like the problems that 33:46.570 --> 33:51.010 are discussed currently, can only occur if you have this way of, that 33:51.010 --> 33:55.050 you have a list of tons, which are just sent to you by SMS, and you 33:55.050 --> 34:00.030 don't have a piece of paper that could be lost or get into the hands 34:00.030 --> 34:00.890 of somebody else. 34:02.650 --> 34:07.390 But if you have this other way of generating tons, then you can only 34:07.390 --> 34:12.290 generate that number if you have your smart card, your secret key, and 34:12.290 --> 34:13.790 things like that, that's more secure. 34:15.070 --> 34:17.950 But we'll come back to those systems a little bit later on. 34:19.010 --> 34:22.730 Okay, so this is, system security definitely is an important topic. 34:22.730 --> 34:25.110 Transaction costs, I mentioned that briefly. 34:25.710 --> 34:30.330 Transaction costs have to do with how we can actually do that, like 34:30.330 --> 34:35.710 how much does it cost to actually process an electronic transaction. 34:36.230 --> 34:40.130 It has to be something which is economical and acceptable. 34:40.570 --> 34:44.570 You don't want to pay more for the transactions than the value of the 34:44.570 --> 34:45.590 payment actually is. 34:46.330 --> 34:49.570 To definitely have some costs, you know that for credit card payments, 34:49.710 --> 34:55.070 you have some fees that are taken by the credit card companies. 34:55.650 --> 34:57.470 You have some transmission costs. 34:58.550 --> 35:01.030 You may have computer access fees or costs. 35:02.290 --> 35:07.770 In Bitcoins, for example, there is some cost involved for information 35:07.770 --> 35:12.150 processing, quite significant amount of information processing that is 35:12.150 --> 35:15.710 necessary in order to validate a transaction. 35:16.790 --> 35:21.670 And so you have to invest something to actually perform a transaction 35:21.670 --> 35:22.290 there. 35:23.010 --> 35:25.250 And so you have some kind of fees there. 35:27.450 --> 35:31.030 And then certainly the cost must be reasonable in relation to the 35:31.030 --> 35:31.870 transmitted value. 35:32.270 --> 35:35.610 In particular, if you have micropayments of just fractions of a cent, 35:36.190 --> 35:40.990 and the cost for processing those micropayments is higher than that, 35:40.990 --> 35:42.130 it doesn't make sense. 35:44.170 --> 35:47.410 Okay, then we have accountability, traceability. 35:48.010 --> 35:52.730 I said that certainly accountability is something which sometimes we 35:52.730 --> 35:54.750 would like to have, but sometimes we don't. 35:58.050 --> 36:03.050 So sometimes you would like to know who has used the money, what the 36:03.050 --> 36:06.130 money has been used for, and where the money has been used. 36:06.130 --> 36:08.970 Also when, another W. 36:09.830 --> 36:14.110 When is also an important part, when the money has been used. 36:14.450 --> 36:22.190 But just the first three are already privacy-related. 36:23.090 --> 36:26.150 And certainly a credit card company would like to know that. 36:26.490 --> 36:29.930 If you look at your credit card statement, you would like to check, 36:31.070 --> 36:32.830 Oh, I don't remember. 36:33.090 --> 36:34.710 What are these payments? 36:34.810 --> 36:37.890 What did I actually buy with my credit card? 36:38.670 --> 36:43.570 And if it only lists the amounts that you paid, and not what you had 36:43.570 --> 36:48.670 actually purchased there, maybe you don't like that. 36:48.730 --> 36:52.650 You would like to see exactly what you have bought where. 36:53.610 --> 36:57.270 And then you have some accountability for what you had spent. 36:58.210 --> 37:01.690 So this is something you would like to have sometimes. 37:03.150 --> 37:07.410 And certainly for criminal activities, tracing that, it's important. 37:09.790 --> 37:12.890 But certainly it has to do with privacy. 37:13.170 --> 37:18.150 You don't want the credit card company to know everything about your 37:18.150 --> 37:19.610 spending habits. 37:20.430 --> 37:25.250 And certainly this information, as we all know, has some commercial 37:25.250 --> 37:25.830 value. 37:25.830 --> 37:30.310 So there is some potential of being attacked. 37:30.510 --> 37:32.210 We know that these events have been there. 37:32.770 --> 37:34.850 So privacy has to do with that. 37:36.730 --> 37:40.490 Sometimes customers would be interested in anonymity. 37:40.990 --> 37:44.490 Service providers will request for traceability. 37:45.210 --> 37:48.750 But sometimes customers also would like to get more information. 37:48.930 --> 37:54.310 So it depends on what interest you actually have currently, what your 37:54.310 --> 37:55.150 context is. 37:55.670 --> 37:58.290 And in some context you would like to have accountability and 37:58.290 --> 37:58.930 traceability. 37:59.470 --> 38:03.370 In the other context, you don't want to provide that accountability. 38:04.970 --> 38:09.150 Then we have online checking requirements, which I mentioned already 38:09.150 --> 38:11.290 in those different systems. 38:11.570 --> 38:17.250 If you have a two-party or three-party system, you would like to 38:17.250 --> 38:18.410 purchase something. 38:18.750 --> 38:23.310 Then the merchant would like to check with the bank whether that 38:23.310 --> 38:29.090 customer actually is able to buy what he wants to get. 38:29.590 --> 38:33.850 If there is sufficient funds available, and only if the bank actually 38:33.850 --> 38:40.810 has certified this customer is good for that amount of money, then you 38:40.810 --> 38:44.770 would actually get that transaction. 38:44.970 --> 38:48.570 The merchant would provide you with the goods and accept that 38:48.570 --> 38:50.410 statement of payment transfer. 38:52.270 --> 38:55.450 Certainly we know that there are different ways of dealing with that. 38:55.490 --> 38:59.150 If you use your bank card, sometimes you only have to sign a certain 38:59.150 --> 38:59.510 slip. 39:00.750 --> 39:02.990 Sometimes you use your PIN. 39:03.810 --> 39:10.130 If you just sign a certain paper slip, then this is just making a 39:10.130 --> 39:10.490 statement. 39:10.490 --> 39:19.550 I state that this transaction is safe. 39:19.630 --> 39:20.530 You will get your money. 39:21.250 --> 39:25.570 In the bank card, the merchant can actually online check when you use 39:25.570 --> 39:26.050 the PIN. 39:26.470 --> 39:29.910 If you just sign something, then you don't use your PIN. 39:29.990 --> 39:33.170 There's no online checking, but it's only checked afterwards. 39:34.130 --> 39:37.230 So if you do without online checking, you bear a larger risk. 39:37.230 --> 39:39.670 You can get an insurance for that. 39:40.290 --> 39:42.490 So you have to pay for it in some way. 39:43.850 --> 39:48.710 So this is a trade-off between having security about payment 39:48.710 --> 39:57.850 transactions or taking some risk and just rely on some other form of 39:57.850 --> 40:00.450 statement, the signature by the customer. 40:02.090 --> 40:05.310 Then you have the topic of acceptability. 40:05.310 --> 40:07.250 I mentioned that already. 40:07.550 --> 40:09.450 So what kind of systems are acceptable? 40:09.470 --> 40:15.270 We all use credit cards or bank cards, like EFT, Post Electronic Fund 40:15.270 --> 40:17.670 Transfer, a point of sale is important. 40:19.050 --> 40:24.750 I was getting upset last week when I was on Hawaii, wanted to get my 40:24.750 --> 40:28.330 use as always, my bank card for getting money, taking money from the 40:28.330 --> 40:29.450 automatic teller machine. 40:29.870 --> 40:33.970 And all of a sudden I noticed that the bank card, the banks had issued 40:33.970 --> 40:39.770 a new bank card with a different system, no longer CIROS, but then it 40:39.770 --> 40:43.910 was V-Pay, and V-Pay is not accepted outside of Europe. 40:44.190 --> 40:45.470 So I couldn't get money there. 40:45.550 --> 40:51.490 I had to use my credit card, which is something which I did not really 40:51.490 --> 40:54.690 know before, but then noticed immediately. 40:55.270 --> 41:00.890 So I was not really willing to accept that the bank card system had 41:00.890 --> 41:01.530 been changed. 41:02.480 --> 41:07.810 So you'd need something which has really widespread use to actually 41:07.810 --> 41:10.990 use those ways of paying. 41:12.030 --> 41:16.950 Smart cards like money card is not actually accepted, or cash cards 41:16.950 --> 41:18.550 are not accepted at many stations. 41:18.990 --> 41:22.130 People use it for public transport. 41:23.370 --> 41:27.450 I don't know, do you have money on your bank card for direct payment? 41:28.470 --> 41:29.850 No, you don't? 41:30.350 --> 41:35.230 I use it, it's very convenient, but certainly then you have some money 41:35.230 --> 41:40.110 there, and it's not really available, it's some virtual money. 41:40.790 --> 41:44.170 Then there are these electronic money systems which I mentioned 41:44.170 --> 41:49.370 already, and what you certainly need is the possibility of 41:49.370 --> 41:54.930 transferring funds between different persons, transferability, another 41:54.930 --> 41:59.310 thing that I had mentioned already, for that you need an open-loop 41:59.310 --> 41:59.830 system. 42:00.450 --> 42:06.590 Open -loop systems are hard to implement in electronic forms, and we 42:06.590 --> 42:11.050 know that transferability for credit cards is not possible, for smart 42:11.050 --> 42:12.710 cards, usually not possible. 42:12.850 --> 42:18.510 There's one system that's been designed actually for transferring 42:18.510 --> 42:26.330 money between smart cards, but that is something which is not really 42:26.330 --> 42:29.810 in widespread use, it's not really available. 42:31.370 --> 42:36.370 And electronic money also has a restricted transferability, usually to 42:36.370 --> 42:44.090 prevent double spending, like the typical e-cash system works in a way 42:44.090 --> 42:50.470 that as soon as you spend e-cash coins, if you would like to check the 42:50.470 --> 42:54.750 validity, at the moment where you check the validity, they get 42:54.750 --> 42:58.670 invalidated, because you have used them once, and that's it. 42:59.970 --> 43:08.650 So this is for just using e-cash coins once, it's not really 43:08.650 --> 43:12.210 equivalent to normal cash. 43:14.330 --> 43:17.730 Divisibility is something which you would like to have for certain 43:17.730 --> 43:21.370 purposes, in particular if you have micropayments, this is something 43:21.370 --> 43:26.310 which is not really that much of a problem. 43:26.770 --> 43:30.750 For electronic systems, you can easily generate any amount, just 43:30.750 --> 43:33.380 define a value, and then... 43:34.050 --> 43:37.350 But if you have electronic coins, they will have specific values, and 43:37.350 --> 43:41.410 you must do it in a way that you can generate any reasonable amount 43:41.410 --> 43:44.790 that you have to pay. 43:45.230 --> 43:50.310 So if you just have one cent coins, it's sufficient, but you would 43:50.310 --> 43:51.950 like to have also larger coins. 43:52.910 --> 43:58.170 Okay, so this was just a general overview of properties of cash 43:58.170 --> 44:02.190 systems or payment systems, and now I would like to look at credit 44:02.190 --> 44:09.130 card systems, how we can actually support payment using credit cards, 44:09.930 --> 44:15.170 and so that's currently the most widespread payment system. 44:16.090 --> 44:21.590 So the bank said, when I complained with respect to the limited use of 44:21.590 --> 44:25.270 the bank card, outside of Europe you just have to use your credit 44:25.270 --> 44:25.670 card. 44:27.630 --> 44:33.130 So we would like to do that in a secure way, because if we use a 44:33.130 --> 44:41.410 credit card, we just usually take the number and then sign, like put 44:41.410 --> 44:45.510 in our name, the number, credit card number, the name, and then we 44:45.510 --> 44:46.210 sign it. 44:48.030 --> 44:52.910 And usually at a gas station, for example, if we pay with credit card, 44:53.330 --> 44:57.910 we would just have our piece of paper, where we have the number, we 44:57.910 --> 45:00.550 have our name, and then we sign it. 45:01.870 --> 45:07.550 If we do this electronically, some people get afraid if they actually 45:07.550 --> 45:10.690 submit their credit card number and their name. 45:11.770 --> 45:15.270 Sometimes you also have a certain three-digit number that you have to 45:15.270 --> 45:21.270 provide as an additional security check, but in electronic 45:21.270 --> 45:23.190 transactions you don't sign it normally. 45:24.010 --> 45:29.030 But a credit card payment is only valid if you have the number, the 45:29.030 --> 45:31.510 name of the owner, and the signature. 45:33.530 --> 45:37.430 You give all that at the gas station to the gas station owner. 45:38.610 --> 45:43.270 You provide all this information, credit card number, name, and 45:43.270 --> 45:43.650 signature. 45:44.050 --> 45:46.450 You don't give that in electronic transactions. 45:47.190 --> 45:51.430 So actually credit card payments without a signature are invalid. 45:53.590 --> 45:57.830 So they're not complete, because a credit card payment is only 45:57.830 --> 46:02.470 complete if you have number, name, and signature. 46:02.810 --> 46:06.810 If you only provide number and name, it's not a complete payment. 46:07.950 --> 46:12.650 So you cannot really insist on getting the money if somebody only 46:12.650 --> 46:16.070 gives you a credit card number and a name, although we know that we 46:16.070 --> 46:21.030 all do it, and we authorize the payments with that. 46:21.610 --> 46:23.470 But you could say, I never did that. 46:23.590 --> 46:28.550 Somebody else used my number and credit card name, and I did not sign 46:28.550 --> 46:29.470 it, so it's not valid. 46:30.310 --> 46:33.750 Then it's the risk of the merchant who actually accepted that payment. 46:34.930 --> 46:38.990 We would like to make that more secure, so we don't want our credit 46:38.990 --> 46:44.110 card numbers and names to be available to everybody, and for that we 46:44.110 --> 46:45.850 need secure communication. 46:46.130 --> 46:48.710 There are different things available. 46:49.390 --> 47:00.710 SSL, a standard way of actually... or TLS, transaction layer security. 47:00.850 --> 47:07.030 SSL, secure socket layers, successor of SSL. 47:07.330 --> 47:11.290 It's just a way of having security on the communication path. 47:11.290 --> 47:13.710 We'll briefly make some statements on that. 47:14.250 --> 47:18.210 There is a... like this is not really related to payments, but it is 47:18.210 --> 47:20.990 providing some security. 47:21.890 --> 47:25.210 Internet key payment protocols derived or developed by IBM. 47:26.310 --> 47:29.670 The IKP had some value for some time. 47:29.850 --> 47:35.790 SET is an interesting protocol because it provides security from 47:35.790 --> 47:40.590 application to application, and this has been designed by MasterCard 47:40.590 --> 47:44.710 and Visa, so by credit card companies. 47:45.410 --> 47:51.990 It's a pity that this nice system is not really used widely because 47:51.990 --> 47:56.870 the license fees are too high, so it's too expensive for the 47:56.870 --> 47:59.570 participants and payments to actually use that. 47:59.650 --> 48:01.570 But it's a very interesting system. 48:02.180 --> 48:06.950 There are some payment servers which also operate based on credit card 48:06.950 --> 48:07.390 systems. 48:07.550 --> 48:10.570 First virtual was the first really payment system. 48:11.190 --> 48:14.190 It's LongDat, CyberCash, another system. 48:14.970 --> 48:17.790 In some ways similar to SET. 48:18.530 --> 48:24.130 Now this is PayPal, so there are systems supporting credit card 48:24.130 --> 48:26.530 payments available in some ways. 48:27.910 --> 48:33.410 Just again, the risks with credit card numbers. 48:33.570 --> 48:35.970 What you provide is your number and your name. 48:36.930 --> 48:43.510 Normally you get some HTML document, some CGI script with forms in it, 48:43.770 --> 48:45.390 so that you provide this information. 48:45.390 --> 48:50.490 An attacker could just modify that script and make sure that 48:55.290 --> 49:00.890 the number, the credit card information is sent to the attacker, so 49:00.890 --> 49:04.450 these modifications are possible, or you get access to those events. 49:04.670 --> 49:10.570 You just eavesdrop the datagrams having that information, and then you 49:10.570 --> 49:12.890 get a list of all kinds of credit cards. 49:13.610 --> 49:19.970 I recently paid with my credit card a larger amount at an American 49:19.970 --> 49:25.570 institution, ordering some quite expensive book for my institute, and 49:25.570 --> 49:28.690 a few days later I got a statement from my credit card company that 49:28.690 --> 49:33.190 they blocked my credit card because there were suspicious 49:33.190 --> 49:36.370 transactions, and actually there were some suspicious transactions 49:36.370 --> 49:40.710 which I did not authorize, and somehow they had detected that, that 49:40.710 --> 49:45.490 these transactions could not have been authorized by myself. 49:45.650 --> 49:49.270 I don't know what kind of intelligent methods they actually used, but 49:49.270 --> 49:50.030 it was effective. 49:51.170 --> 49:56.750 So there somebody actually got that information, somehow eavesdropped 49:56.750 --> 50:02.550 that transaction that I had with that other company, and then used my 50:02.550 --> 50:03.830 credit card number and name. 50:04.670 --> 50:09.510 But you have to detect that, and certainly I would have noticed that, 50:10.410 --> 50:14.170 because it's traceable, what happens there, and could have said, no, 50:14.330 --> 50:15.990 that's not authorized by me. 50:17.350 --> 50:17.910 Okay. 50:18.750 --> 50:22.690 Ways of protection certainly are you use authentication, you use more 50:22.690 --> 50:27.650 than just number and name, and that's what SCT is about. 50:28.330 --> 50:34.810 First of all, SSL has been designed by Netscape some time ago, has 50:34.810 --> 50:38.570 been extended to transport layer security, and what it does, it 50:38.570 --> 50:44.670 authenticates the client servers that you are using for some 50:44.670 --> 50:45.370 communication. 50:46.050 --> 50:55.150 So this is something which is making TCP connections more secure. 50:55.150 --> 51:05.050 So you have your sockets at the source and receiver, like sender and 51:05.050 --> 51:08.730 receiver, you make some transaction here, and you would like to make 51:08.730 --> 51:14.530 sure that this communication over the TCP connection is secure, is 51:14.530 --> 51:14.990 encrypted. 51:15.610 --> 51:20.870 So for that, so this is the TCP level, and on top of that, you have 51:20.870 --> 51:30.870 TLS, which is making this communication between TCP sockets more 51:30.870 --> 51:31.310 secure. 51:31.690 --> 51:41.290 It's not providing you with more security between your application on 51:41.290 --> 51:41.850 this side. 51:41.930 --> 51:46.890 So if you have an application here and there, this part here from the 51:46.890 --> 51:58.150 application to TLS is plain text, only what goes through TLS via TCP 51:58.150 --> 52:01.530 to the recipient, that's secure. 52:02.210 --> 52:06.550 So it is making the communication channel more secure, so it's a 52:06.550 --> 52:10.590 service making that more secure, but it's not dealing with the path 52:10.590 --> 52:12.770 from the application to TLS. 52:14.610 --> 52:19.730 And so it authenticates client and server, uses digital signatures, 52:20.190 --> 52:25.310 uses encryption of documents, and it uses exactly those typical 52:25.310 --> 52:29.590 protocols that I have presented to you at the end of the last chapter, 52:29.990 --> 52:33.930 combination of asymmetric and symmetric methods with different 52:33.930 --> 52:37.450 asymmetric methods like RSA or Diffie-Hellman, which I did not present 52:37.450 --> 52:43.270 to you, and then these symmetric methods and signature mechanisms. 52:45.090 --> 52:49.250 And for that, it's important to, first of all, certainly agree which 52:49.250 --> 52:57.930 kind of methods could be used, and this is shown briefly on the next 52:57.930 --> 52:58.310 slide. 52:59.690 --> 53:05.730 You can see the switch from secure to insecure transactions by 53:05.730 --> 53:08.970 difference between, for example, HTTPS and HTTP. 53:08.970 --> 53:15.310 If it's HTTPS, you are using TLS secure communication. 53:16.910 --> 53:18.550 So what is actually done? 53:18.870 --> 53:19.670 Very simplified. 53:19.850 --> 53:20.990 You have the client and the server. 53:21.590 --> 53:27.150 You send the typical hello message and information on cryptographic 53:27.150 --> 53:32.890 capabilities and some random number to the server, and then this is 53:32.890 --> 53:40.270 sent back from the server to the client, specifies the cryptographic 53:40.270 --> 53:44.110 method that can be used by the server. 53:44.690 --> 53:48.150 So the cryptographic capabilities are sent by the client and then the 53:48.150 --> 53:52.530 appropriate ones, the highest possible or the most secure 53:52.530 --> 53:55.170 cryptographic method is used. 53:55.570 --> 53:57.050 You get some certificate. 53:57.850 --> 54:00.990 We know that we need certificates for asymmetric methods. 54:01.670 --> 54:06.270 You get the certificate request, and here you need, like sometimes you 54:06.270 --> 54:09.230 use that random number in an appropriate way. 54:10.170 --> 54:16.130 The client will specify his or her certificate for the method that 54:16.130 --> 54:19.110 actually has to be used, that is agreed upon. 54:20.270 --> 54:27.150 And then also the symmetric key that is encoded with the server's 54:27.150 --> 54:27.810 public key. 54:27.990 --> 54:33.630 As you know, we use session keys for those communication protocols. 54:33.630 --> 54:36.730 And then this protocol is finished. 54:36.850 --> 54:43.290 You can use that symmetric key for the transaction that is built up in 54:43.290 --> 54:46.290 that TLS session. 54:47.090 --> 54:51.950 Then both sides say that agreement is finished and they can actually 54:51.950 --> 54:53.550 make use of the symmetric key. 54:53.750 --> 54:58.050 They have the certificates and can use secure communication. 54:58.250 --> 55:02.530 This is essentially the protocol that I showed to you on the last 55:02.530 --> 55:03.610 slide of the last chapter. 55:03.690 --> 55:04.230 Do you have a question? 55:09.200 --> 55:11.680 It's not shown here. 55:12.120 --> 55:21.720 Sometimes, like for some ways of agreeing on a session key, you just 55:21.720 --> 55:23.100 provide that random number. 55:23.220 --> 55:24.700 I don't go into the details here. 55:24.780 --> 55:27.800 This is used in this protocol. 55:27.800 --> 55:31.680 I'm not going into the details at this moment. 55:35.460 --> 55:40.200 This is part of the Diffie-Hellman algorithm. 55:40.460 --> 55:44.140 You use those random numbers usually. 55:52.760 --> 55:57.860 Agreement on the use of certificates and on methods, you sometimes 55:57.860 --> 56:02.220 need that random number to make sure that you don't have... 56:02.220 --> 56:04.840 or that man-in-the-middle attacks are prevented. 56:05.180 --> 56:09.460 That's the major reason for that random number that you are using 56:09.460 --> 56:09.780 here. 56:11.860 --> 56:15.280 After that, you have the exchange of application data. 56:17.700 --> 56:26.020 This is using that symmetric key just for this transaction, for this 56:26.020 --> 56:29.060 session, this TCP session, for this connection. 56:30.480 --> 56:32.380 Certainly, it might be a longer session. 56:32.500 --> 56:37.320 You can send several documents, but for every connection, you have a 56:37.320 --> 56:38.720 new symmetric key. 56:40.160 --> 56:47.060 I didn't want to go really deeply into SSL because that's not really 56:47.060 --> 56:51.560 related to secure payment methods. 56:51.840 --> 56:55.260 I would like to concentrate on secure payment methods. 56:55.920 --> 56:59.440 I certainly could give you more information on that, on the explicit 56:59.440 --> 57:03.020 use of the random number, but you can also look it up in the protocols 57:03.020 --> 57:07.020 for SSL or TLS and then find it out yourself. 57:08.760 --> 57:15.300 Let's concentrate on secure electronic transactions, SET, because it 57:15.300 --> 57:19.260 has interesting concepts which extend the concepts that I have shown 57:19.260 --> 57:19.980 you before. 57:20.840 --> 57:24.780 Here, certain requirements are stated. 57:25.120 --> 57:29.300 In the outset, we would like to have confidentiality of information, 57:29.700 --> 57:33.060 which usually we don't have in credit card payments. 57:33.800 --> 57:38.680 The confidentiality is there with respect to the payment event and the 57:38.680 --> 57:39.420 purchase order. 57:39.920 --> 57:45.400 These are considered separately because certainly the payment event 57:45.400 --> 57:50.400 need not be completely known to the merchant. 57:51.840 --> 57:57.660 The merchant will only have interest in getting the money, but need 57:57.660 --> 58:02.360 not know complete account information of the customer. 58:03.060 --> 58:08.400 And the bank need not know everything about what actually is being 58:08.400 --> 58:14.840 bought and where, but only the amount of money that is requested and 58:14.840 --> 58:18.540 whether there is sufficient money on the account, whether that can be 58:18.540 --> 58:19.540 authorized or not. 58:20.480 --> 58:25.880 And so these two events, these two different aspects, are treated 58:25.880 --> 58:26.520 separately. 58:27.520 --> 58:32.840 And so what we have here is an interesting requirement, which so far 58:32.840 --> 58:39.460 were not there in the way we talked about safety of those things. 58:39.740 --> 58:42.640 So then the data integrity certainly is important. 58:42.840 --> 58:46.220 We need digital signatures to make sure that payment statements 58:46.220 --> 58:50.180 actually cannot be modified or we can detect modifications. 58:50.600 --> 58:53.660 And we need authentication of merchant and customer. 58:54.500 --> 58:59.400 So we would like to know whether the merchant would like to know 58:59.400 --> 59:03.340 whether the customer actually has a valid credit card account and the 59:03.340 --> 59:06.620 customer would like to know whether that merchant actually is 59:06.620 --> 59:08.180 authorized to accept credit cards. 59:08.940 --> 59:11.000 So you need this authentication. 59:13.020 --> 59:18.880 And this is done using quite some sophisticated protocol involving 59:18.880 --> 59:22.780 three parties, the customer, the merchant, and the bank. 59:23.300 --> 59:26.380 And there are several transactions that have to be done in that 59:26.380 --> 59:26.980 communication. 59:27.480 --> 59:32.140 You have to initiate a request for buying something. 59:33.000 --> 59:38.980 The merchant will respond with some message how such a transaction can 59:38.980 --> 59:39.420 be done. 59:39.620 --> 59:40.720 You need some information. 59:41.200 --> 59:45.760 As in the other communications, you need information on certificates, 59:46.040 --> 59:47.540 on keys, and things like that. 59:48.080 --> 59:52.940 Then you can actually send the purchase order using the information 59:52.940 --> 59:56.060 you got from the merchant, using, for example, public key 59:56.060 --> 59:56.900 certificates. 59:58.060 --> 01:00:01.240 You would like to get a response on a purchase order. 01:00:01.240 --> 01:00:07.200 Now the merchant would like to know whether the customer can actually 01:00:07.200 --> 01:00:07.600 pay. 01:00:08.080 --> 01:00:11.780 So you send some information, some authorization request for that 01:00:11.780 --> 01:00:13.840 money transfer to the bank. 01:00:15.000 --> 01:00:19.120 The bank has to send back a response, whether that is authorized or 01:00:19.120 --> 01:00:19.420 not. 01:00:20.200 --> 01:00:26.040 And the customer could check whether the status or what the status 01:00:26.040 --> 01:00:26.980 actually is. 01:00:27.640 --> 01:00:31.100 The merchant can send back some information whether that has been 01:00:31.100 --> 01:00:32.080 authorized or not. 01:00:32.980 --> 01:00:38.880 And at the end, the merchant would like to get actually the money in 01:00:38.880 --> 01:00:44.240 exchange for some information that, like this authorization response, 01:00:44.440 --> 01:00:49.840 should allow the merchant to, at some later time, actually transfer 01:00:49.840 --> 01:00:52.240 that statement into real money. 01:00:53.900 --> 01:00:57.740 So this payment capture response has to state the money has been 01:00:57.740 --> 01:00:59.080 transferred to your account. 01:01:00.820 --> 01:01:05.220 How this is done is explained in more details on the next slides. 01:01:07.080 --> 01:01:10.400 For this, every participant has two public key pairs. 01:01:11.280 --> 01:01:15.040 Not just one public key pair, but there are two public key pairs. 01:01:15.200 --> 01:01:19.620 One is used just for digital signatures, for signing documents, and 01:01:19.620 --> 01:01:22.040 the other one is used for sending session keys. 01:01:23.600 --> 01:01:33.120 And these keys have to be used in this way, so we don't have just one 01:01:33.120 --> 01:01:34.580 pair of keys, but two. 01:01:35.800 --> 01:01:40.460 The public keys are verified using a certification hierarchy. 01:01:40.920 --> 01:01:45.020 So we assume that we have some public key infrastructure with certain 01:01:45.020 --> 01:01:49.140 certificates, like these certificate chains, as you know. 01:01:50.780 --> 01:01:56.400 And if you have an SET purchase order, it has the following form. 01:01:56.820 --> 01:01:59.280 We have two statements, two separate statements. 01:01:59.960 --> 01:02:04.620 One is the customer message to the merchant, stating what the customer 01:02:04.620 --> 01:02:05.560 would like to buy. 01:02:06.460 --> 01:02:10.580 And the second part, the yellow part here, is the customer message to 01:02:10.580 --> 01:02:11.180 the bank. 01:02:12.280 --> 01:02:13.480 Both are sent. 01:02:14.040 --> 01:02:16.920 And now I said it should provide some anonymity. 01:02:17.920 --> 01:02:25.940 And so the merchant gets both messages, both parts, the order 01:02:25.940 --> 01:02:30.300 information and the payment information, but the payment information 01:02:30.300 --> 01:02:33.180 should be hidden from the merchant. 01:02:34.120 --> 01:02:42.100 So certainly both messages have to be digitally signed. 01:02:42.840 --> 01:02:47.220 And now the interesting point is that the two parts, the order 01:02:47.220 --> 01:02:52.200 information and the payment information, are treated separately. 01:02:52.820 --> 01:02:58.000 So you generate a message digest for both parts, one for the order 01:02:58.000 --> 01:03:02.940 information, one for the payment information, and then you generate a 01:03:02.940 --> 01:03:07.540 digest of both digests, you combine those two into one message digest, 01:03:08.240 --> 01:03:11.920 and then you generate a signature. 01:03:12.810 --> 01:03:18.720 And now this signature is a signature of both documents, but in order 01:03:18.720 --> 01:03:26.860 to verify the signature, what you need is a message digest, so you can 01:03:26.860 --> 01:03:32.360 verify the customer message, the merchant can verify whether he can 01:03:32.360 --> 01:03:42.480 generate a message digest when he receives this order information, can 01:03:42.480 --> 01:03:49.840 generate the message digest and check whether this message digest, 01:03:50.520 --> 01:03:54.160 like if you have the message digest also of the payment information, 01:03:54.320 --> 01:03:58.420 even without knowing the payment information, you can combine the 01:03:58.420 --> 01:04:04.680 generated message digest with the message digest that you get without 01:04:04.680 --> 01:04:10.040 looking at the customer message, and you can generate the digest of 01:04:10.040 --> 01:04:15.220 digests, and then you can, from the dual signature, you can find out 01:04:15.220 --> 01:04:19.420 whether the integrity is still there. 01:04:19.740 --> 01:04:25.100 So integrity check works, even if you only have one part, only the 01:04:25.100 --> 01:04:30.660 order information and the message digest related to the payment 01:04:30.660 --> 01:04:36.040 information, or you have the payment information and the message 01:04:36.040 --> 01:04:39.340 digest of the order information, even if you don't have the order 01:04:39.340 --> 01:04:39.940 information. 01:04:40.880 --> 01:04:44.580 And so the bank can check the validity of the signature, the merchant 01:04:44.580 --> 01:04:48.940 can check the validity of the signature, of the dual signature, but 01:04:48.940 --> 01:04:54.420 they don't get information on the payment or on the order. 01:04:55.060 --> 01:04:59.420 So this is the major point of that dual signature. 01:04:59.420 --> 01:05:05.100 The yellow part here, the payment information is encrypted using a 01:05:05.100 --> 01:05:14.020 session key and the bank's public key, and only the bank can decrypt 01:05:14.020 --> 01:05:22.280 that session key for decrypting the customer message, so the merchant 01:05:22.280 --> 01:05:26.580 cannot do that because you use the bank's public key, only the secret 01:05:26.580 --> 01:05:28.600 key of the bank can decrypt that. 01:05:29.300 --> 01:05:33.160 So the merchant can only read his part of the message and the 01:05:33.160 --> 01:05:37.520 encrypted payment information, the dual signature and the hidden 01:05:37.520 --> 01:05:39.800 session key are forwarded to the bank. 01:05:41.180 --> 01:05:45.220 We will look at details of that in a moment. 01:05:46.080 --> 01:05:49.280 And so the payment information is hidden from the merchant, the order 01:05:49.280 --> 01:05:54.420 information is hidden from the bank, and so you have different ways of 01:05:54.420 --> 01:06:00.120 anonymity here dependent on what kind of information is needed for the 01:06:00.120 --> 01:06:07.480 two different functionalities to provide a certain good that you would 01:06:07.480 --> 01:06:12.040 like that was purchased or transferring the money. 01:06:13.100 --> 01:06:17.260 So order information is hidden from the bank, that's the concept of 01:06:17.260 --> 01:06:21.860 the dual signature, that's the major reason why I present this concept 01:06:21.860 --> 01:06:31.100 because I think this is an interesting way of achieving this anonymity 01:06:31.100 --> 01:06:33.800 in a three-party payment event. 01:06:34.420 --> 01:06:39.880 The different things that are done here are briefly indicated here, 01:06:39.900 --> 01:06:45.260 the first four things, you have to initiate a request, send the 01:06:45.260 --> 01:06:51.300 request from the cardholder to the merchant, the merchant sends back 01:06:51.300 --> 01:06:55.820 the response, and then the cardholder receives the response, sends a 01:06:55.820 --> 01:07:02.700 request to complete the order and payment information, this is 01:07:02.700 --> 01:07:14.300 received by the merchant, and then the cardholder will get certain... 01:07:14.300 --> 01:07:19.760 actually the certificates are only sent afterwards and we will look at 01:07:19.760 --> 01:07:24.340 these individual communication events on the next slides. 01:07:25.660 --> 01:07:27.160 So what is sent initially? 01:07:28.260 --> 01:07:30.800 This is just... 01:07:31.580 --> 01:07:33.960 it's some initial... 01:07:36.020 --> 01:07:40.240 oh, this is the initial response, so this is actually the response 01:07:40.240 --> 01:07:45.280 from the merchant to the cardholder, and what is the merchant sending? 01:07:45.280 --> 01:07:51.880 It is sending a digital signature, so this is the... 01:07:52.880 --> 01:07:58.740 it is generating a message digest, the merchant's private signature 01:07:58.740 --> 01:08:03.880 key is used to encrypt the message digest on that response to the 01:08:03.880 --> 01:08:11.540 request of the customer, and then you have a digital signature of that 01:08:11.540 --> 01:08:12.040 response. 01:08:12.040 --> 01:08:13.340 So this is the digital signature. 01:08:13.740 --> 01:08:20.180 In order to certify that that is actually correct, you need the 01:08:20.180 --> 01:08:23.020 merchant certificate signature key. 01:08:23.320 --> 01:08:29.680 I said that the merchant has sent you the digital signature. 01:08:29.980 --> 01:08:36.880 In order to check the signature, you need the public key related to 01:08:36.880 --> 01:08:38.560 that signature key pair. 01:08:38.700 --> 01:08:39.260 You have a question? 01:08:43.700 --> 01:08:46.660 A PIN number is not a digital signature. 01:08:48.920 --> 01:08:50.440 I wouldn't say so. 01:08:50.580 --> 01:08:52.940 A PIN number is something which you... 01:08:52.940 --> 01:08:58.220 a PIN normally is not just used once. 01:09:00.660 --> 01:09:01.160 Yes. 01:09:11.030 --> 01:09:11.750 Yes. 01:09:20.120 --> 01:09:24.380 So if you pay with your credit card, sometimes you... 01:09:24.960 --> 01:09:29.160 like you can have an additional security... 01:09:30.540 --> 01:09:37.020 extra security functionality where you get a PIN number sent by SMS. 01:09:37.700 --> 01:09:37.880 No. 01:09:39.300 --> 01:09:40.400 Just your PIN number. 01:09:40.440 --> 01:09:42.480 That's a PIN number which is always the same. 01:09:44.000 --> 01:09:44.380 Yes. 01:09:45.200 --> 01:09:51.580 And you could say this is some kind of secret key that you use, but 01:09:51.580 --> 01:09:52.920 it's not really... 01:09:52.920 --> 01:09:58.780 like it's not providing you with information that actually combines... 01:09:59.440 --> 01:10:04.160 like it's not a combination really of the event and the... 01:10:04.160 --> 01:10:08.400 like it's not comparable to a secret key. 01:10:08.760 --> 01:10:17.160 It's just some secret that you have in some way agreed upon to use and 01:10:17.160 --> 01:10:18.300 this can be... 01:10:18.300 --> 01:10:24.220 like this is a very simple way of having a secret that is known to you 01:10:24.220 --> 01:10:27.340 and to the credit card company or to the bank. 01:10:28.060 --> 01:10:31.860 And if you type in your PIN number, it is checked whether the PIN 01:10:31.860 --> 01:10:33.100 number actually is valid. 01:10:34.300 --> 01:10:36.640 It's not comparable to a digital signature. 01:10:37.520 --> 01:10:41.480 Because in a digital signature you have to generate the digest and 01:10:41.480 --> 01:10:47.440 then you use the secret key to generate that digital signature and you 01:10:47.440 --> 01:10:48.580 can... 01:10:49.120 --> 01:10:55.480 like the recipient, any recipient, can verify whether that is a valid 01:10:55.480 --> 01:10:59.560 digital signature by just using the public key because you can 01:10:59.560 --> 01:11:03.160 generate the digest that you decrypted from the digital signature. 01:11:03.760 --> 01:11:07.080 You can also generate the digest from the document and compare whether 01:11:07.080 --> 01:11:09.720 those digests are the same. 01:11:10.820 --> 01:11:15.100 And so this has much more functionality than using a PIN. 01:11:17.160 --> 01:11:22.500 Okay, so here you have the cardholder gets this information back from 01:11:22.500 --> 01:11:23.540 the merchant. 01:11:23.720 --> 01:11:31.240 So it gets a way of authenticating the merchant and it also gets the 01:11:31.240 --> 01:11:36.640 payment gateways certificate key exchange key. 01:11:36.840 --> 01:11:37.740 So what is that? 01:11:38.420 --> 01:11:39.760 The key exchange key. 01:11:40.740 --> 01:11:43.900 The key exchange key is... 01:11:44.700 --> 01:11:46.900 I said there are two pairs of public... 01:11:49.660 --> 01:11:52.400 two key pairs for... 01:11:52.400 --> 01:11:57.040 one used for digital signatures and one used for key exchange. 01:11:59.400 --> 01:12:05.320 The key exchange is necessary for exchanging the session keys which 01:12:05.320 --> 01:12:08.120 are only used for this one payment event. 01:12:08.760 --> 01:12:14.320 And for that you need the payment gateways certificate key or 01:12:14.320 --> 01:12:16.200 certificate for the key exchange key. 01:12:17.280 --> 01:12:23.140 The certificate provides you with the public key for using that or for 01:12:23.140 --> 01:12:24.500 encrypting the session key. 01:12:24.720 --> 01:12:28.340 We will use or we will see in the next slide how that is used. 01:12:30.960 --> 01:12:41.620 So actually the cardholder can take from that... 01:12:41.620 --> 01:12:46.560 like from that initiate or this initial response. 01:12:46.560 --> 01:12:51.160 You can generate a message digest because you know the method that is 01:12:51.160 --> 01:12:51.620 used. 01:12:52.120 --> 01:12:55.260 You can decrypt. 01:12:55.400 --> 01:12:56.700 What can you decrypt? 01:12:57.780 --> 01:13:02.500 You can decrypt the digital signature using the public key of the 01:13:02.500 --> 01:13:05.320 merchant which is contained in that certificate. 01:13:06.040 --> 01:13:11.400 From that you get the message digest for that response and you can 01:13:11.400 --> 01:13:12.920 check the validity of that. 01:13:12.920 --> 01:13:16.120 We know that mechanism for integrity check. 01:13:17.300 --> 01:13:23.660 And then the cardholder can generate a purchase order by doing the 01:13:23.660 --> 01:13:24.040 following. 01:13:25.140 --> 01:13:27.760 You generate ordering information. 01:13:27.960 --> 01:13:29.740 You generate payment information. 01:13:30.520 --> 01:13:34.660 The ordering information is sent in plain text to the merchant but you 01:13:34.660 --> 01:13:38.100 need a signature for checking the integrity. 01:13:38.100 --> 01:13:43.780 So you generate a message digest for the ordering information and the 01:13:43.780 --> 01:13:44.680 payment information. 01:13:45.040 --> 01:13:50.700 You generate the combined message digest of the ordering and the 01:13:50.700 --> 01:13:57.360 payment or of the digests of those two ordering and payment 01:13:57.360 --> 01:13:58.040 information. 01:13:58.280 --> 01:14:07.360 You encrypt the message digest using your private key and that's the 01:14:07.360 --> 01:14:13.520 private signature key of the cardholder and then you have your dual 01:14:13.520 --> 01:14:14.040 signature. 01:14:16.620 --> 01:14:22.580 And then you do the following. 01:14:23.240 --> 01:14:39.740 You take the payment information and the dual signature. 01:14:40.840 --> 01:14:41.860 That is this here. 01:14:43.420 --> 01:14:51.700 And you encrypt using some symmetric key, some session key. 01:14:52.020 --> 01:14:54.240 You encrypt that payment information. 01:14:54.400 --> 01:14:56.880 You have the encrypted payment message. 01:14:59.640 --> 01:15:03.120 Now, what else do you send to the merchant? 01:15:03.460 --> 01:15:07.640 You send the encrypted payment message which contains payment 01:15:07.640 --> 01:15:09.320 information and dual signature. 01:15:10.480 --> 01:15:17.260 So the merchant cannot decrypt that unless the merchant would have the 01:15:17.260 --> 01:15:17.940 symmetric key. 01:15:18.980 --> 01:15:26.300 This symmetric key is taken together with the account data is 01:15:26.300 --> 01:15:35.340 encrypted using the payment gateway's public key exchange key. 01:15:35.660 --> 01:15:42.280 So only the payment gateway can decrypt that information on the 01:15:42.280 --> 01:15:44.780 symmetric key and on the account data. 01:15:46.060 --> 01:15:48.820 Only the payment gateway can do that. 01:15:51.100 --> 01:15:54.180 And so what does the merchant get? 01:15:54.180 --> 01:15:56.520 It gets the encrypted payment message. 01:15:56.700 --> 01:16:03.820 It gets the encrypted session key but cannot do anything with it 01:16:03.820 --> 01:16:05.820 because it cannot decrypt that. 01:16:06.360 --> 01:16:12.680 It also gets the ordering information and the dual signature. 01:16:14.580 --> 01:16:20.720 And the cardholder's signature key certificate. 01:16:21.140 --> 01:16:28.220 So the public key of the cardholder because then the cardholder's 01:16:28.220 --> 01:16:31.020 private key has been used to generate the dual signature. 01:16:31.240 --> 01:16:34.840 This has to be verified using the public key of the cardholder. 01:16:35.520 --> 01:16:40.560 So on the next slide we see what the merchant can do. 01:16:41.220 --> 01:16:46.020 It gets the message digest of the payment information. 01:16:47.240 --> 01:16:55.040 It gets the ordering information, the dual signature, and now can use 01:16:55.040 --> 01:16:58.380 the cardholder's public key 01:17:02.120 --> 01:17:05.040 to decrypt the dual signature. 01:17:05.900 --> 01:17:09.780 That provides the combined message digest. 01:17:10.940 --> 01:17:18.860 You can generate a message digest of the ordering information, combine 01:17:18.860 --> 01:17:24.100 that with the received message digest of the payment information, 01:17:24.940 --> 01:17:30.040 generate the combined message digest, and compare both. 01:17:32.860 --> 01:17:38.540 So here what the merchant does, it can generate the message digest 01:17:38.540 --> 01:17:43.640 responding to the received ordering information, use the payment 01:17:43.640 --> 01:17:49.780 information digest without having information on the real content of 01:17:49.780 --> 01:17:55.920 the payment message, and check whether that is correct with respect to 01:17:55.920 --> 01:17:58.840 the received dual signature. 01:18:00.880 --> 01:18:06.940 And then the purchase response is just the response using again a 01:18:06.940 --> 01:18:07.600 digital signature. 01:18:07.780 --> 01:18:08.960 This is more or less trivial. 01:18:10.860 --> 01:18:15.860 Then the cardholder can decrypt that again. 01:18:16.000 --> 01:18:19.620 This is again just looking at a digital signature communication or 01:18:19.620 --> 01:18:24.120 digital signature check, just an integrity check of that simple 01:18:24.120 --> 01:18:25.200 purchase response. 01:18:25.940 --> 01:18:29.580 And now the interesting parts are how the payment is actually 01:18:29.580 --> 01:18:30.320 authorized. 01:18:31.280 --> 01:18:36.580 So the merchant has to send the information to the bank for 01:18:36.580 --> 01:18:41.220 authorization or to the payment gateway for authorization of that 01:18:41.220 --> 01:18:45.360 payment, and the payment gateway has to send back some authorization 01:18:45.360 --> 01:18:46.120 response. 01:18:47.160 --> 01:18:52.700 So here in that request, the merchant has to transfer or to forward 01:18:52.700 --> 01:18:54.420 the relevant information. 01:18:55.200 --> 01:18:56.680 So what has to be forwarded? 01:18:56.720 --> 01:18:58.220 Some authorization request. 01:18:59.640 --> 01:19:05.600 So this is something which is giving some information on the merchant 01:19:05.600 --> 01:19:06.500 to the bank. 01:19:06.760 --> 01:19:12.480 This certainly is signed using the signature key of the merchant. 01:19:15.040 --> 01:19:20.180 This authorization request usually is also encrypted, making it 01:19:20.180 --> 01:19:20.720 confidential. 01:19:22.220 --> 01:19:24.660 So nobody else can look at that. 01:19:25.340 --> 01:19:30.080 So this information on, because there is the payment information or 01:19:30.080 --> 01:19:33.820 the account information of the merchant is contained in that, so it 01:19:33.820 --> 01:19:34.600 should be encrypted. 01:19:36.400 --> 01:19:43.340 This symmetric key has to be encrypted using the payment gateway's 01:19:43.340 --> 01:19:44.620 public key. 01:19:46.080 --> 01:19:52.040 And so the bank or the payment gateway can decrypt that message. 01:19:53.060 --> 01:19:58.200 And then the ordering information or the payment information from the 01:19:58.200 --> 01:19:59.640 cardholder has to be sent. 01:20:00.260 --> 01:20:04.620 So here we have the payment instruction, the encrypted payment 01:20:04.620 --> 01:20:10.200 message, plus the payment digital envelope, which was on the previous 01:20:10.200 --> 01:20:15.300 slide, what the cardholder had sent to the merchant. 01:20:15.760 --> 01:20:19.860 This is forwarded to the payment gateway together with several 01:20:19.860 --> 01:20:20.480 certificates. 01:20:21.200 --> 01:20:25.240 It is the cardholder's certificate for the signature key. 01:20:26.060 --> 01:20:32.800 Then the payment gateway can retrieve or can check the integrity of 01:20:32.800 --> 01:20:34.260 what the cardholder has done. 01:20:35.100 --> 01:20:39.300 The merchant certificate for the signature key because the merchant 01:20:39.300 --> 01:20:44.300 has also generated a signature that's this one. 01:20:45.660 --> 01:20:48.520 So this is a standard signature, not a dual signature. 01:20:49.180 --> 01:20:53.740 This key here, the first one, was necessary for using the dual 01:20:53.740 --> 01:20:54.240 signature. 01:20:55.040 --> 01:21:00.400 And then there is the merchant certificate key exchange key that is 01:21:00.400 --> 01:21:05.340 the certificate or the public key which allows to actually... 01:21:06.040 --> 01:21:09.220 this is the merchant certificate key exchange. 01:21:09.680 --> 01:21:15.780 Yeah, this is the public key because then the payment gateway can 01:21:15.780 --> 01:21:22.920 actually send back information to the merchant again encrypted in some 01:21:22.920 --> 01:21:23.200 way. 01:21:24.380 --> 01:21:26.640 So you see that this... 01:21:26.640 --> 01:21:31.280 it is a complicated protocol but it's always using the same procedure. 01:21:32.300 --> 01:21:37.500 It's always using this way of signing something and sometimes you use 01:21:37.500 --> 01:21:41.960 a dual signature that's the initial authorization request or the 01:21:41.960 --> 01:21:47.380 initial ordering request and then you use all these different 01:21:47.380 --> 01:21:51.620 certificates, public keys, secret keys and so on in order to perform 01:21:51.620 --> 01:21:53.700 integrity and authentication checks. 01:21:54.100 --> 01:22:00.800 So the payment gateway can get the authorization request which has 01:22:00.800 --> 01:22:05.020 been encrypted using some session key generated by the merchant. 01:22:05.140 --> 01:22:12.840 This is decrypted using the payment gateway's private key exchange 01:22:12.840 --> 01:22:13.180 key. 01:22:14.440 --> 01:22:19.300 And then you get the authorization request and some digital signature. 01:22:20.120 --> 01:22:25.940 That digital signature can be decrypted using the merchant's public 01:22:27.180 --> 01:22:32.560 key exchange... no, the public signature key and then you can perform 01:22:32.560 --> 01:22:39.160 the integrity check and the other part was the payment message the 01:22:39.160 --> 01:22:44.460 encrypted payment information from the cardholder and this payment 01:22:44.460 --> 01:22:48.420 digital envelope with the account information and the dual signature 01:22:48.420 --> 01:22:56.160 actually is decrypted and in this way the payment gateway retrieves 01:22:56.160 --> 01:23:02.540 the dual signature retrieves the payment information and again can 01:23:02.540 --> 01:23:09.480 perform the integrity check by appropriate use of hash functions and 01:23:10.920 --> 01:23:12.480 Public and private keys. 01:23:13.040 --> 01:23:13.160 Okay. 01:23:14.020 --> 01:23:15.440 And then, this is continued. 01:23:15.620 --> 01:23:17.460 I don't want to go into all the details. 01:23:17.720 --> 01:23:19.340 You can just look it up yourself. 01:23:19.980 --> 01:23:25.800 It's always using, essentially, that protocol which I showed you on 01:23:25.800 --> 01:23:27.620 the last slide of the previous chapter. 01:23:28.220 --> 01:23:30.820 So, a combination of all these different things. 01:23:31.360 --> 01:23:39.520 By the way, here, what this response of the payment gateway actually 01:23:39.520 --> 01:23:44.200 is some capture token message. 01:23:44.340 --> 01:23:50.800 Now, this capture token message, which is sent to the merchant, is 01:23:50.800 --> 01:23:53.200 encrypted using a session key. 01:23:54.220 --> 01:24:00.260 And the session key is encrypted using the payment gateway's public 01:24:00.260 --> 01:24:02.460 key exchange key. 01:24:03.340 --> 01:24:09.300 Now, the payment gateway sends something encrypted such that only the 01:24:09.300 --> 01:24:11.280 payment gateway can decrypt that. 01:24:12.180 --> 01:24:17.840 It means the merchant gets this information, but this is only a token 01:24:17.840 --> 01:24:25.040 which cannot be opened by the merchant, but it can be used at a later 01:24:25.040 --> 01:24:25.900 point in time. 01:24:26.940 --> 01:24:31.840 It can be sent back to the payment gateway, or then to the bank. 01:24:31.840 --> 01:24:38.660 And the payment gateway can open that and proceed as specified in that 01:24:38.660 --> 01:24:39.480 statement. 01:24:39.840 --> 01:24:43.600 But the payment gateway has already reserved the amount of money 01:24:44.440 --> 01:24:46.520 corresponding to that payment request. 01:24:47.200 --> 01:24:53.140 And so, at any later time, this capture token can be used by the 01:24:53.140 --> 01:24:54.900 merchant to actually retrieve the money. 01:24:55.620 --> 01:24:58.420 But only the payment gateway can open that. 01:24:59.140 --> 01:25:05.240 The merchant only gets that as some kind of token, which can be used 01:25:05.240 --> 01:25:07.700 later on as a payment request. 01:25:08.700 --> 01:25:14.240 So this is what is indicated here, the capture request and the capture 01:25:14.240 --> 01:25:16.560 response, using that capture token. 01:25:17.440 --> 01:25:21.220 And that's the remainder of that protocol. 01:25:21.220 --> 01:25:30.480 And then the money is actually safely deposited to the account of the 01:25:30.480 --> 01:25:30.800 merchant. 01:25:31.480 --> 01:25:35.540 This is summarizing all the properties of SCT. 01:25:35.920 --> 01:25:37.940 The major point is the dual signature. 01:25:38.780 --> 01:25:42.460 The other point was the capture token and the use of two separate 01:25:42.460 --> 01:25:43.200 public keys. 01:25:43.400 --> 01:25:47.120 Those are the three major parts of that SCT protocol. 01:25:47.120 --> 01:25:52.240 It's a complex protocol, but it provides security between the 01:25:52.240 --> 01:25:52.980 applications. 01:25:54.420 --> 01:25:59.740 Security with respect to confidentiality, anonymity to relevant 01:25:59.740 --> 01:26:08.760 parties, and also integrity checks. 01:26:09.140 --> 01:26:13.620 So this is really secure, but it turned out to be too complex for 01:26:13.620 --> 01:26:18.100 practical usage because the license fees, operation costs were too 01:26:18.100 --> 01:26:21.900 high and people don't use that, which is a pity. 01:26:22.160 --> 01:26:22.960 It's a nice protocol. 01:26:23.500 --> 01:26:25.040 Okay, that's it for today. 01:26:25.240 --> 01:26:26.020 Thank you for your attention.