WEBVTT 00:01.590 --> 00:01.930 Okay. 00:02.970 --> 00:06.030 So, welcome to another session on Algorithms for Internet 00:06.030 --> 00:06.690 Applications. 00:07.190 --> 00:09.430 Today, I'm handicapped in two ways. 00:10.870 --> 00:19.270 I have a cold, as you can hear, and I forgot the pen for my tablet PC. 00:19.870 --> 00:25.350 So, it's a bit difficult today to make any annotations on the slides, 00:25.590 --> 00:27.990 but I hope it's okay. 00:27.990 --> 00:32.710 So, let's just briefly look at what we did last week. 00:32.810 --> 00:36.150 I showed you a bit more about electronic payment systems. 00:36.950 --> 00:37.090 Oops. 00:43.340 --> 00:44.900 Why doesn't this work? 00:49.650 --> 00:50.750 This is just awful. 00:52.690 --> 00:52.970 Okay. 00:54.750 --> 00:57.610 So, I showed you different levels of payment systems. 00:57.970 --> 00:59.650 These three different levels. 00:59.810 --> 01:01.690 The third level being the open loop system. 01:01.690 --> 01:10.750 And we then looked at some criteria for evaluating payment systems. 01:11.770 --> 01:20.030 And we looked at, or started to look also at, some specific systems. 01:20.670 --> 01:24.470 A simple way of paying is using credit cards. 01:24.590 --> 01:28.930 And I showed you that there are some protocols around for that. 01:29.770 --> 01:34.630 There is the secure socket layer, which is certainly not designed for 01:34.630 --> 01:40.310 secure payments, but for any secure communication. 01:40.950 --> 01:45.430 Although the application level is not secure, but only the link 01:45.430 --> 01:49.650 between the two TCP protocols. 01:50.050 --> 01:52.630 So, only the channel is secure, but not the application. 01:52.630 --> 01:57.690 And then we looked at the secure electronic transactions. 01:58.270 --> 02:00.150 And I showed you last time this slide. 02:00.250 --> 02:03.630 This was, I think, the last slide of last time. 02:04.830 --> 02:07.630 Not exactly the last, but the next one I showed also. 02:08.410 --> 02:13.710 So here, what you see here is the essential part of the, or the 02:13.710 --> 02:21.150 essential design element of the secure electronic transaction system. 02:21.810 --> 02:26.350 In particular, the dual signature, which is a signature of two parts 02:26.350 --> 02:30.690 of the information that has to be transmitted. 02:31.110 --> 02:36.770 There is one part that is transmitted to the merchant, which is the 02:36.770 --> 02:37.690 order information. 02:38.250 --> 02:41.790 And there is another part that is transmitted, or to be transmitted to 02:41.790 --> 02:45.550 the financial institution, which is the payment information. 02:46.710 --> 02:51.090 And the merchant really does not need to look at the payment 02:51.090 --> 02:56.770 information, since he only wants to get the money, but it's of no 02:56.770 --> 03:00.570 relevance to him what the account number, or credit card number, or 03:00.570 --> 03:02.990 whatsoever is of this customer. 03:04.070 --> 03:08.310 And in the same way, the payment institution, or the financial 03:08.310 --> 03:13.190 institution, should not be interested in knowing what the customer 03:13.190 --> 03:14.170 wants to buy. 03:14.590 --> 03:19.350 The only point is that the financial institution has to check whether 03:19.350 --> 03:23.090 there is, whether the balance on the account of the customer is 03:23.090 --> 03:25.750 sufficiently large to make this payment. 03:26.770 --> 03:31.410 So, this is the reason why we have this splitted information, order 03:31.410 --> 03:33.030 information, and payment information. 03:33.170 --> 03:35.550 And you will see how this is actually handled. 03:36.430 --> 03:44.530 So, then we have these two parts are separately secured using the 03:44.530 --> 03:50.550 digest, producing a message digest. 03:51.110 --> 03:56.990 Then both digests are again compressed into a digest of the digest, as 03:56.990 --> 03:58.730 you see here. 03:59.110 --> 04:04.110 And then we have a dual signature, that means we have a signature in 04:04.110 --> 04:10.810 encryption with a private key of the customer, showing that this is a 04:10.810 --> 04:14.890 signature of the digest of digest. 04:15.190 --> 04:19.830 And now you will see in the next slides how this actually is used. 04:20.850 --> 04:24.410 And we go to the next slide. 04:24.610 --> 04:28.110 And here, yeah, this was, I did not show this last time. 04:28.110 --> 04:31.790 So, we should go into the presentation mode. 04:32.570 --> 04:40.810 And I will try to use just the cursor to underline a few things 04:40.810 --> 04:41.350 sometimes. 04:42.170 --> 04:44.650 Or maybe I should not do that. 04:44.750 --> 04:49.750 It is too hard to draw with this thing here. 04:49.750 --> 04:51.970 You see, I cannot see anymore. 04:53.670 --> 04:55.950 This is ridiculous. 04:56.950 --> 04:57.750 Now I have it. 04:58.350 --> 04:59.010 There it is. 05:00.130 --> 05:05.190 I should switch back to the arrow, so now I can see it. 05:05.230 --> 05:05.910 This is better. 05:06.570 --> 05:12.490 Okay, so this is the SCT communication between the customer and the 05:12.490 --> 05:12.770 merchant. 05:13.510 --> 05:20.130 You see there are four communication parts here that are indicated. 05:20.790 --> 05:26.170 There is the initial request by the customer. 05:26.370 --> 05:29.130 The cardholder sends a message to the merchant. 05:29.950 --> 05:37.870 Then the merchant sends his certificate with the response to the 05:37.870 --> 05:38.430 cardholder. 05:38.430 --> 05:44.950 And then the cardholder can send the order information. 05:45.830 --> 05:47.510 He sends the purchase request. 05:48.310 --> 05:56.430 And afterwards, the merchant can send the acknowledgement of that 05:56.430 --> 05:59.410 purchase request. 05:59.990 --> 06:01.710 So this is the purchase response. 06:01.850 --> 06:05.150 And we will see on the next slide how this is actually done. 06:05.150 --> 06:09.810 I will not show you all the individual parts of this protocol in the 06:09.810 --> 06:13.210 slides that you have already printed out. 06:13.350 --> 06:16.490 You can see that there are many steps in there. 06:16.890 --> 06:19.410 And I only want to outline a few things here. 06:20.190 --> 06:28.090 So what you can see is that we have here the initial response. 06:29.090 --> 06:33.790 And everything in this communication between the customer and the 06:33.790 --> 06:40.690 merchant is made safe using exactly the protocol that I showed you at 06:40.690 --> 06:43.510 the end of the last chapter. 06:44.930 --> 06:47.770 So there is this initiate response. 06:48.110 --> 06:51.930 This is encrypted or signed with a digital signature. 06:52.610 --> 06:58.230 And so this is the response to the initial request by the customer. 06:58.910 --> 07:06.530 In this response, the merchant uses his private signature key for 07:06.530 --> 07:08.590 producing this digital signature. 07:09.650 --> 07:14.890 And then he puts both into the message that has to be sent to the 07:14.890 --> 07:15.350 customer. 07:15.350 --> 07:17.030 This is the response. 07:17.210 --> 07:22.890 The format of that response is outlined in the specification of the 07:22.890 --> 07:23.750 SCT protocol. 07:24.510 --> 07:27.590 It's not necessary to go into the details of that response. 07:28.190 --> 07:36.670 This is just information on the merchant and some details on this 07:36.670 --> 07:40.470 protocol, which is not that relevant really. 07:40.470 --> 07:45.470 The relevant parts are how this communication is done in a secure way. 07:46.390 --> 07:49.530 And so we have this response in plain text. 07:49.730 --> 07:51.270 We have the digital signature. 07:52.230 --> 07:58.450 And the merchant has to send his certificate for the signature key. 07:59.230 --> 08:04.410 Otherwise, the customer would not be able to decrypt the signature, as 08:04.410 --> 08:04.790 you know. 08:04.790 --> 08:10.690 We also have another certificate, which has to be sent. 08:11.390 --> 08:19.210 The merchant sends the certificate key from the financial institution, 08:19.370 --> 08:20.890 the payment gateways. 08:21.190 --> 08:25.690 Certificate key for the exchange key. 08:25.870 --> 08:28.290 Now, why would you need something like that? 08:31.590 --> 08:34.050 You will see in a moment why we need that. 08:35.290 --> 08:37.630 I can show you that on the next slide. 08:37.790 --> 08:40.110 I think it's better to do that. 08:40.250 --> 08:43.630 This message is sent to the cardholder. 08:44.510 --> 08:53.790 And then the cardholder gets this message, as you guys just saw on the 08:53.790 --> 08:54.670 last slide. 08:55.290 --> 08:57.230 Now, what can the cardholder do with that? 08:57.230 --> 09:04.470 He can produce a message digest, because he knows the message digest 09:04.470 --> 09:05.270 function. 09:05.830 --> 09:13.870 He can decrypt the digital signature, because he knows the merchant's 09:13.870 --> 09:16.590 signature key, or the public key. 09:17.070 --> 09:19.290 This is retrieved from the certificate. 09:20.090 --> 09:26.630 Then, with the public key of this merchant's signature key, he can 09:26.630 --> 09:32.250 decrypt the signature, get the digest, compare the two, and check the 09:32.250 --> 09:32.830 integrity. 09:34.610 --> 09:35.750 So, that's very simple. 09:36.270 --> 09:38.150 Then, this gets a bit more complex. 09:38.510 --> 09:40.450 Now, the purchase order is compiled. 09:41.010 --> 09:41.770 How is that done? 09:42.430 --> 09:44.790 So, we have this, and now we have this dual signature. 09:45.290 --> 09:47.670 The order information, we have the payment information. 09:47.670 --> 09:50.690 Details of both are not relevant. 09:51.630 --> 09:56.530 They are specified exactly, like the format of those is exactly 09:56.530 --> 10:00.770 specified in the specification of the SET. 10:01.450 --> 10:05.410 So, both are compressed into a digest. 10:05.770 --> 10:08.070 The order information and payment information digest. 10:08.670 --> 10:13.530 Then, those two are compressed again, and signed, encrypted with the 10:13.530 --> 10:15.390 cardholder's private signature key. 10:15.390 --> 10:17.070 So, you get the dual signature. 10:18.230 --> 10:25.370 Now, this, together with the payment information, is encrypted using 10:25.370 --> 10:26.690 some session key. 10:27.430 --> 10:28.890 So, this is a symmetric key. 10:29.270 --> 10:34.710 It's a session key, and this is put here into the message that is sent 10:34.710 --> 10:35.370 to the merchant. 10:35.990 --> 10:38.330 This is the encrypted payment message. 10:38.330 --> 10:48.110 Encrypted, well, because the merchant should not be able to look at 10:48.110 --> 10:49.490 the payment information. 10:50.690 --> 10:55.770 So, all the customer's payment information is put into that payment 10:55.770 --> 10:56.290 message. 10:57.450 --> 11:02.190 Then, this symmetric key certainly is needed by the recipient to 11:02.190 --> 11:04.850 decrypt this encrypted payment information. 11:04.850 --> 11:14.710 Now, this session key and account data of the customer are encrypted 11:14.710 --> 11:19.230 using the payment gateway's public key exchange key. 11:20.650 --> 11:27.330 So, the payment gateway has a key exchange key, and the customer got 11:27.330 --> 11:31.230 this public key from the merchant. 11:31.510 --> 11:33.670 This was the second certificate that he sent. 11:33.670 --> 11:40.130 And so, now the customer can encrypt the session key using the payment 11:40.130 --> 11:43.410 gateway's public key exchange key. 11:44.510 --> 11:51.090 And so, only the payment gateway can decrypt the session key, which 11:51.090 --> 11:56.230 means that the merchant will not be able to access the information in 11:56.230 --> 11:57.790 this payment message. 11:58.350 --> 12:00.690 So, now we have all the payment information. 12:01.410 --> 12:06.690 In addition to that, the message digest of the payment information is 12:06.690 --> 12:06.950 sent. 12:08.170 --> 12:09.590 Now, why do we need that? 12:09.630 --> 12:12.750 You will see that in a moment, where that is needed. 12:14.230 --> 12:20.410 Then, we have the, this here is called the payment digital envelope, 12:20.650 --> 12:23.570 which is the encrypted session key plus the account data. 12:24.450 --> 12:29.950 And then, we need the order information, which is sent in plain text 12:29.950 --> 12:31.690 to the merchant. 12:32.650 --> 12:40.950 And the dual signature is also included in that message to the 12:40.950 --> 12:42.070 merchant. 12:42.430 --> 12:47.070 And the cardholder has to send his own certificate, because the public 12:47.070 --> 12:51.870 key is needed for decrypting the signature. 12:51.870 --> 12:55.370 So, this is the purchase order. 12:55.890 --> 12:58.750 Now, what does the merchant do with that? 12:59.250 --> 13:02.490 The merchant has to check whether everything is correct. 13:03.130 --> 13:07.930 So, he does not care about the encrypted payment message, but he 13:07.930 --> 13:10.890 certainly has to check whether this has been signed correctly. 13:11.430 --> 13:18.690 What he can do is, he can take the order information and produce the 13:18.690 --> 13:20.370 order information message digest. 13:20.370 --> 13:28.290 Now, in order to check whether the signature is actually still okay, 13:29.070 --> 13:32.490 he has to combine the order information message digest with the 13:32.490 --> 13:34.070 payment information message digest. 13:34.450 --> 13:39.650 Therefore, this payment information message digest had to be sent in 13:39.650 --> 13:45.450 addition to this encrypted payment message, just in order to enable 13:45.450 --> 13:48.690 the merchant to check the signature. 13:48.690 --> 13:53.650 So, the merchant will decrypt the dual signature by using the 13:53.650 --> 13:57.910 cardholder's public signature key, which is retrieved from the 13:57.910 --> 14:01.090 cardholder's signature key certificate. 14:02.410 --> 14:11.250 And then, he decrypts the dual signature, gets the message digest, and 14:11.250 --> 14:17.650 can compare whether the message digest that is computed from the two 14:17.650 --> 14:20.430 message digests here is still the same. 14:21.170 --> 14:24.150 This is now the verification of a dual signature. 14:25.010 --> 14:30.050 So, even if you only get part of the document, you still can detect 14:30.050 --> 14:34.730 whether the dual signature is correct, because you have here the 14:34.730 --> 14:36.790 correct message digest. 14:37.790 --> 14:44.230 Okay, so this is a case where you check the integrity of a document, 14:44.490 --> 14:49.430 the payment information, without actually accessing that document. 14:50.250 --> 14:55.870 So, certainly the merchant could replace this payment message with 14:55.870 --> 15:03.370 something else, but then, at a later point in time, that execution 15:03.370 --> 15:07.410 that will actually check the contents of the payment message after 15:07.410 --> 15:13.170 decryption will find out that payment message and message digest don't 15:13.170 --> 15:14.370 coincide. 15:15.430 --> 15:19.010 Okay, so this is what the merchant has to do with that. 15:19.010 --> 15:27.670 And then, there is this purchase response where the merchant just 15:27.670 --> 15:29.670 acknowledges that he has got everything. 15:30.890 --> 15:39.910 And then, the customer gets the purchase response and does the obvious 15:39.910 --> 15:40.350 things. 15:40.530 --> 15:45.010 He decrypts the signature again and checks the validity. 15:45.830 --> 15:50.170 And then, we get the payment authorization communication between the 15:50.170 --> 15:52.330 merchant and the financial institution. 15:53.170 --> 15:57.330 And here, we have the authorization request. 15:57.490 --> 16:03.170 The merchant wants to check whether the customer's credit card is good 16:03.170 --> 16:09.550 for this payment, and so he sends the information to the payment 16:09.550 --> 16:10.010 gateway. 16:10.550 --> 16:11.950 Now, what does he have to send? 16:11.950 --> 16:20.690 He has to send this authorization request, which is again signed in a 16:20.690 --> 16:21.270 digital way. 16:22.590 --> 16:28.090 And this digital signature together with the authorization request is 16:28.090 --> 16:35.070 actually encrypted, just so that nobody else can access that. 16:36.070 --> 16:42.210 Now, we have the encrypted authorization request with a symmetric key 16:42.210 --> 16:44.910 here, a session key. 16:45.070 --> 16:50.110 This session key is encrypted using the payment gateway's public key 16:50.110 --> 16:51.050 exchange key. 16:51.490 --> 16:56.450 Then, we have here the digital envelope of that session key and this 16:56.450 --> 16:58.010 encrypted authorization request. 16:58.970 --> 17:00.370 And what else? 17:01.450 --> 17:07.930 The merchant has to forward the encrypted payment information, this 17:07.930 --> 17:14.270 message here, and has to send that together with the payment digital 17:14.270 --> 17:14.870 envelope. 17:15.830 --> 17:18.470 So, this was part of the message that he got from the customer. 17:18.710 --> 17:20.470 He has to forward that to the payment gateway. 17:21.270 --> 17:27.490 And he has to forward the cardholder's certificate in order to allow 17:27.490 --> 17:31.470 the payment gateway to check that signature. 17:32.630 --> 17:39.610 He has to send his own certificates for his signature key and for the 17:39.610 --> 17:40.410 exchange key. 17:40.610 --> 17:41.830 So, two certificates. 17:42.690 --> 17:47.670 That's sent to the payment gateway, and there it is, just retrieved in 17:47.670 --> 17:48.530 the obvious way. 17:48.530 --> 17:53.330 This looks a bit complex, but it is again and again the same 17:53.330 --> 17:53.930 procedure. 17:54.710 --> 17:59.030 It is always using the information that you have. 17:59.430 --> 18:03.590 So here, for example, to decrypt this encrypted authorization request, 18:04.110 --> 18:06.850 the bank needs the symmetric key. 18:07.670 --> 18:12.750 This is retrieved from this digital envelope, which can be opened by 18:12.750 --> 18:16.530 using the payment gateway's private key, which the banks or the 18:16.530 --> 18:19.850 payment gateway certainly has in a secure place. 18:20.550 --> 18:24.670 And then the payment gateway gets the symmetric key, can decrypt, and 18:24.670 --> 18:30.030 then can check the validity as usual, and can check whether the 18:30.030 --> 18:31.570 message digest coincides. 18:31.710 --> 18:34.310 So, that's just a data integrity check. 18:34.790 --> 18:38.870 The same now is done with the customer part of the information, this 18:38.870 --> 18:40.330 payment information from the customer. 18:40.330 --> 18:49.110 And here, you see it's certainly important that in the authorization 18:49.110 --> 18:57.390 request, actually, the merchant had to put also the order information 18:57.390 --> 19:01.470 message digest, because the bank certainly has to check the dual 19:01.470 --> 19:01.990 signature. 19:03.050 --> 19:07.990 And so, the bank needs this order information message digest. 19:07.990 --> 19:13.150 It has retrieved the payment information message digest, and now it 19:13.150 --> 19:20.370 can combine both into this combined digest, and check with the digest 19:20.370 --> 19:24.430 retrieved from the dual signature that was decrypted using the 19:24.430 --> 19:25.610 cardholder's public key. 19:26.710 --> 19:31.630 So, now the payment gateway has all the information it needs. 19:32.210 --> 19:39.270 And now, the payment gateway will send a request to the cardholder's 19:39.270 --> 19:44.690 financial institution in order to check whether... 19:44.690 --> 19:46.410 So, the payment gateway is just a gateway. 19:47.670 --> 19:54.110 And the payment gateway sends a request to the cardholder's financial 19:54.110 --> 19:54.690 institution. 19:54.690 --> 20:02.030 All the information about that was sent in the payment information by 20:02.030 --> 20:02.630 the customer. 20:03.670 --> 20:14.070 And now, we have to see what's happening there in this authorization. 20:14.510 --> 20:20.330 So, if that is authorized, the payment gateway will send an 20:20.330 --> 20:21.690 authorization response. 20:22.690 --> 20:24.870 And there is now one important point. 20:24.950 --> 20:29.450 So, here we have the standard things, the encrypted authorization 20:29.450 --> 20:34.050 message plus the encrypted session key. 20:35.330 --> 20:39.750 And then, we get something more. 20:39.870 --> 20:42.270 We get here a so-called capture token. 20:42.270 --> 20:44.410 Now, what is the capture token? 20:45.030 --> 20:52.130 It is a token, some piece of information that, if you have that, you 20:52.130 --> 20:57.190 are entitled to get money from the cardholder's financial institution. 20:58.750 --> 21:02.270 Now, this capture token, as you see here... 21:02.850 --> 21:07.610 So, this was received from the cardholder's financial institution with 21:07.610 --> 21:10.230 the approval that he has sufficient amount of money. 21:10.230 --> 21:13.750 And then, this is encrypted with the session key. 21:15.490 --> 21:23.470 Now, this symmetric key or this capture token is encrypted using the 21:23.470 --> 21:26.350 payment gateways, public key exchange key. 21:26.990 --> 21:32.790 The payment gateway encrypts this capture token with its own public 21:32.790 --> 21:33.990 key exchange key. 21:34.810 --> 21:43.270 That means only the payment gateway will be able to decrypt this 21:43.270 --> 21:46.030 encrypted capture token message. 21:46.710 --> 21:54.970 Nevertheless, this is compiled into this capture token message plus 21:54.970 --> 21:56.530 capture token digital envelope. 21:57.550 --> 22:03.570 The purpose is that the merchant should only get this piece of 22:03.570 --> 22:04.130 information. 22:04.970 --> 22:08.750 But the merchant should not be able to modify it in any way. 22:10.090 --> 22:14.990 Therefore, there is no need for the merchant to access this capture 22:14.990 --> 22:15.470 token. 22:15.470 --> 22:20.070 This capture token is something which has to be sent to the bank at 22:20.070 --> 22:24.590 some later time when the merchant wants to get money after he has 22:24.590 --> 22:28.290 actually delivered the product that was to be purchased. 22:29.310 --> 22:34.150 And so, the merchant only needs this encrypted piece of information, 22:34.610 --> 22:39.590 certainly plus some more information that tells this payment has been 22:39.590 --> 22:43.830 authorized and you can deliver the product. 22:44.910 --> 22:48.510 And then certainly, like we have here, this encrypted authorization 22:48.510 --> 22:52.310 message which is all this information that is relevant to the 22:52.310 --> 22:52.590 merchant. 22:53.130 --> 23:00.170 But this essential payment information for retrieving the money is 23:00.170 --> 23:04.350 only encrypted and not accessible to the merchant. 23:04.530 --> 23:10.050 But it is certainly retrieved or received by the merchant when he 23:10.050 --> 23:11.910 receives this message. 23:13.070 --> 23:18.010 So, this is the receipt of the authorization response. 23:18.510 --> 23:24.090 The merchant can decrypt the authorization message, can check the 23:24.090 --> 23:29.070 validity, the integrity in the normal way and nothing happens with 23:29.070 --> 23:32.210 that payment information with the capture token. 23:32.970 --> 23:38.950 And so, after that, after the merchant has actually delivered the 23:38.950 --> 23:44.670 product, the merchant or the computer of the merchant actually issues 23:44.670 --> 23:48.330 this capture request to the payment gateway. 23:48.990 --> 23:52.190 And the payment gateway will send after that a capture response. 23:52.290 --> 23:53.630 And we will see how that is done. 23:53.630 --> 23:58.950 The payment capture request is done in the following way. 23:59.150 --> 24:08.390 This capture request is... what do we have to put in there? 24:08.390 --> 24:18.610 We have here the capture request which is some request by the merchant 24:18.610 --> 24:22.970 with some information again specified what kind of information has to 24:22.970 --> 24:23.550 be in there. 24:23.930 --> 24:26.510 This has to be signed again in the normal way. 24:26.510 --> 24:34.210 And certainly this capture request, if it is encrypted, has to be... 24:34.210 --> 24:37.930 or you have to encrypt the session key for the payment gateway's 24:37.930 --> 24:38.530 public key. 24:39.170 --> 24:43.550 And certainly the capture request, we need this capture token, this 24:43.550 --> 24:46.750 encrypted information that had been sent to the merchant before. 24:47.270 --> 24:49.190 And this is sent now to the payment gateway. 24:49.710 --> 24:54.950 The payment gateway can receive this capture request by the merchant. 24:55.870 --> 24:59.990 Using the merchant's certificate. 25:01.110 --> 25:06.310 And it can retrieve this previously encrypted capture token. 25:07.050 --> 25:11.710 And now get this capture token, can check whether everything here is 25:11.710 --> 25:12.090 correct. 25:13.130 --> 25:15.470 So, it has now this capture token. 25:17.430 --> 25:21.410 Okay, and now this capture token is used to retrieve the money. 25:21.690 --> 25:26.350 This capture token is sent for the capture request. 25:26.490 --> 25:30.870 The capture token is sent by the payment gateway to the cardholder's 25:30.870 --> 25:33.390 financial institution, the issuer of the credit card. 25:34.290 --> 25:43.950 And then this transfer of funds is initiated. 25:43.950 --> 25:49.830 And after that, the payment gateway sends back to the merchant a 25:49.830 --> 25:52.950 response and states that everything is okay. 25:54.050 --> 25:56.910 So, this looks like a complicated protocol. 25:57.150 --> 25:59.590 Certainly, there are many ingredients in there. 25:59.970 --> 26:05.330 But you see that we have many instances of that communication protocol 26:05.330 --> 26:07.170 that I showed you last time. 26:08.060 --> 26:17.390 The major properties of this algorithm, of this protocol are this dual 26:17.390 --> 26:23.550 signature, which certainly is a very important part, allowing for 26:23.550 --> 26:25.950 partial anonymity. 26:26.950 --> 26:30.190 So, the payment information is only visible to the bank. 26:30.510 --> 26:32.730 The order information is only visible to the merchant. 26:33.470 --> 26:37.190 And it also allows for integrity checks as necessary. 26:38.070 --> 26:41.330 Then we have these two separate public key pairs for exchanging 26:41.330 --> 26:42.030 session keys. 26:42.570 --> 26:45.550 So, this is something which is usually done with a public key pair. 26:45.670 --> 26:48.290 You always state the purpose of that key. 26:48.690 --> 26:51.870 And you have one for signing and one for sending session keys. 26:53.230 --> 26:55.870 And then we have here these capture tokens. 26:55.870 --> 27:01.650 And this is also an important part of the protocol that you get this 27:01.650 --> 27:03.030 capture token. 27:04.350 --> 27:08.690 So, this capture token is the piece of information that is also 27:08.690 --> 27:13.610 certainly memorized at the cardholder financial institution. 27:13.890 --> 27:18.870 The cardholder financial institution acknowledged that the balance is 27:18.870 --> 27:20.430 okay for this cardholder. 27:20.430 --> 27:25.250 But certainly it has to remember that it did that or that it gave that 27:25.250 --> 27:25.770 acknowledgement. 27:26.330 --> 27:30.610 So, this has to be stored there at the cardholder's financial 27:30.610 --> 27:31.630 institution's place. 27:32.950 --> 27:40.110 And then this capture token is sent out in order to make sure that as 27:40.110 --> 27:46.270 soon as that is retrieved again, this transfer of funds actually shall 27:46.270 --> 27:47.130 be done. 27:47.870 --> 27:55.330 And so, this capture token must not be modified in between. 27:56.030 --> 28:00.610 And so, we have this protocol where this capture token is only sent in 28:00.610 --> 28:02.150 an encrypted way to the merchant. 28:03.330 --> 28:08.170 And then retrieved or re-sent again to the payment gateway, which can 28:08.170 --> 28:12.270 decrypt it and send it to the cardholder's financial institution. 28:12.270 --> 28:15.750 Okay, that is the SAT protocol. 28:16.290 --> 28:17.870 You see, it is a bit complex. 28:18.730 --> 28:23.270 And the problem is that the software that you certainly need in order 28:23.270 --> 28:26.750 to support that was not very cheap. 28:27.290 --> 28:31.490 And I think something like 5,000 euro was the amount of money 28:31.490 --> 28:32.930 merchants had to pay for that. 28:33.450 --> 28:36.230 And so, it just was not spread. 28:36.410 --> 28:37.190 It was not used. 28:37.430 --> 28:38.970 It was not put into use. 28:38.970 --> 28:45.130 It is a very good protocol because it allows for a much higher degree 28:45.130 --> 28:48.370 of anonymity than you usually have in credit card payments. 28:49.090 --> 28:54.710 But it is not always the best algorithm that is used. 28:54.930 --> 28:55.570 You have a question? 29:03.230 --> 29:03.490 Sorry? 29:05.910 --> 29:10.630 Well, the question was about the certification authorities. 29:10.630 --> 29:15.750 All the certificates that you have here certainly have to be 29:15.750 --> 29:18.950 certificates certified by some certification authority. 29:20.410 --> 29:25.870 And if I say I retrieve a public key from a certificate, I certainly 29:25.870 --> 29:29.170 always have to check whether this certificate is correct. 29:29.510 --> 29:32.450 So, I check the digital signature of the certificate as I showed you 29:32.450 --> 29:34.810 when I told you about the public key infrastructure. 29:35.950 --> 29:38.210 So, this is always associated with that. 29:38.590 --> 29:42.950 Or it may be that you have a web of trust which is the basis of that. 29:43.030 --> 29:47.230 But normally, in such a system, it would be public key infrastructure 29:47.230 --> 29:49.110 based on certification authorities. 29:50.290 --> 29:56.730 And you certainly need some initial trust. 29:56.730 --> 30:03.570 In fact, you need some trustable public key of this certification 30:03.570 --> 30:07.010 authority in order to be able to check the validity of the 30:07.010 --> 30:07.570 certificates. 30:08.610 --> 30:09.810 Was that your question? 30:14.430 --> 30:14.750 Yes. 30:17.790 --> 30:21.850 If you do not have a certificate for your keys, you cannot take part 30:21.850 --> 30:22.790 in such a process. 30:23.950 --> 30:31.890 This is based on the availability of certificates that are issued by 30:31.890 --> 30:33.010 certification authorities. 30:33.710 --> 30:34.970 This is a major point. 30:35.270 --> 30:39.670 This certainly shows in order to use this, you need a public key 30:39.670 --> 30:40.230 infrastructure. 30:42.110 --> 30:47.310 And in Germany, as I told you, we have this very nice legislation with 30:47.310 --> 30:49.070 three levels of signatures. 30:50.470 --> 30:54.170 And the requirements are, as I said, very high. 30:54.810 --> 30:59.830 And so, we do not actually have a widespread use of high level digital 30:59.830 --> 31:00.270 signatures. 31:00.970 --> 31:06.370 And so, we do not actually have such a widespread public key 31:06.370 --> 31:06.890 infrastructure. 31:07.870 --> 31:12.950 Who of you does have a certificate issued by the university's 31:12.950 --> 31:14.090 certification authority? 31:15.330 --> 31:15.990 Nobody. 31:16.450 --> 31:17.370 Why don't you have that? 31:17.370 --> 31:20.830 You can get it for free. 31:21.750 --> 31:25.490 You will need that at some later time when you use all the services 31:25.490 --> 31:27.290 that we are developing. 31:28.730 --> 31:39.030 So, it is true that, like, who of you uses public key encryption? 31:40.810 --> 31:41.830 You use it. 31:41.970 --> 31:42.430 Just one. 31:42.430 --> 31:45.690 Okay, but with PGP or with a different system? 31:46.730 --> 31:47.310 A different. 31:47.490 --> 31:48.950 What kind of system do you use? 31:52.420 --> 31:57.640 Okay, but if you want to sign documents with Adobe, you certainly need 31:57.640 --> 31:58.220 a certificate. 31:59.680 --> 32:02.980 You need some certified public key. 32:04.760 --> 32:06.420 Okay, a very signed key. 32:06.700 --> 32:08.080 Okay, you can do that. 32:09.120 --> 32:12.520 But you know that the university issues certificates. 32:13.600 --> 32:16.740 And so, for communication, you can use those. 32:16.980 --> 32:21.680 You get them for free, and it can be a benefit to you. 32:22.680 --> 32:27.560 And as I said, if you want to make use of all the future services that 32:27.560 --> 32:29.140 we develop, you will need certificates. 32:29.820 --> 32:30.220 Okay. 32:32.280 --> 32:33.080 So, 32:44.390 --> 32:46.150 these are the properties of SCT. 32:46.850 --> 32:52.890 And then there is this other protocol, CyberCache, which is a bit more 32:52.890 --> 32:53.330 simple. 32:55.370 --> 32:56.970 Looks similar. 32:57.790 --> 33:02.150 I will just show you this here. 33:02.150 --> 33:03.790 I have this brief animation. 33:04.010 --> 33:04.890 I hope it works. 33:10.950 --> 33:12.430 Aha, you see. 33:13.750 --> 33:14.850 That's a mistake. 33:16.070 --> 33:18.830 Okay, I will not display this animation. 33:19.130 --> 33:22.810 It doesn't really provide that much new information. 33:22.930 --> 33:24.490 I can just show it to you on this here. 33:24.830 --> 33:33.370 CyberCache is another system for supporting credit card information on 33:33.370 --> 33:35.210 a PC. 33:35.210 --> 33:39.570 Oh, by the way, I checked that animation before, and it worked. 33:39.730 --> 33:44.190 Maybe the problem is that I had to move everything on my new tablet 33:44.190 --> 33:48.990 PC, so that it doesn't work anymore, but I checked that. 33:49.890 --> 33:57.950 And sometimes I have this problem when I want to access such a file 33:57.950 --> 34:02.230 from a PowerPoint presentation. 34:02.230 --> 34:05.890 Somehow it doesn't work correctly. 34:07.050 --> 34:13.610 And the funny thing is that it always works safely in my study room at 34:13.610 --> 34:16.210 home, but it doesn't work in class. 34:16.490 --> 34:18.870 So, that's a very strange behavior of these systems. 34:19.510 --> 34:21.490 So, we have this computer here. 34:21.550 --> 34:22.970 The consumer wants to buy something. 34:23.790 --> 34:29.270 And here you have just the normal protected communication channel 34:29.270 --> 34:30.430 using SSL. 34:30.430 --> 34:41.170 And the merchant gets a request and will again send this request, the 34:41.170 --> 34:44.250 payment information to the bank payment server. 34:44.910 --> 34:47.050 There are some firewalls in here. 34:48.030 --> 34:57.270 And then we have another communication with the merchant's bank or a 34:57.270 --> 35:02.050 third -party processor, depending on what kind of payment transaction 35:02.050 --> 35:04.810 actually is supposed to be done. 35:05.130 --> 35:09.410 Then you have communication between the merchant's bank and the 35:09.410 --> 35:14.610 cardholder's bank, transfer of money, information is sent back, and 35:14.610 --> 35:20.790 the merchant gets the money, or the statement that he got the money, 35:21.250 --> 35:25.990 and he will deliver the flowers that were bought to the consumer. 35:25.990 --> 35:31.950 So, the important point here is that we do have encrypted information 35:31.950 --> 35:34.890 in here, but it's only based on SSL. 35:34.990 --> 35:38.230 It's not based on such a sophisticated protocol as an SET. 35:38.910 --> 35:43.150 The security here does not extend to the application level, but it is 35:43.150 --> 35:48.230 only on the communication levels in this system. 35:49.670 --> 35:58.350 Then there are nice other ideas, interesting ideas of how you could 35:58.350 --> 36:06.670 actually integrate payment systems in other applications. 36:07.640 --> 36:15.190 Fun here is the name of a company at Karlsruhe, which is very strong 36:15.190 --> 36:19.430 in software for financial applications. 36:20.030 --> 36:25.490 In particular, they have quite a few products for secure payments, all 36:25.490 --> 36:26.390 kinds of products. 36:27.810 --> 36:30.090 And this idea here is quite nice. 36:30.450 --> 36:32.310 So, what does it do? 36:33.190 --> 36:38.410 It is a system where the customer wants to get something from the 36:38.410 --> 36:38.750 merchant. 36:39.690 --> 36:46.330 And now the merchant, like he opens the internet page, the web page of 36:46.330 --> 36:49.350 the merchant, and now the customer has to pay. 36:49.470 --> 36:55.730 And if he has to pay, you just get a link to the customer's home 36:55.730 --> 36:56.750 banking interface. 36:57.790 --> 37:06.010 So, the customer just states his bank, where he has his account, and 37:06.010 --> 37:11.650 then you get a new page displayed with a home banking interface. 37:12.110 --> 37:17.390 And then you use just your normal home banking procedures to pay. 37:17.390 --> 37:27.590 And in this home banking interface, you get this transfer statement 37:27.590 --> 37:32.490 for the funds, with all the information in there. 37:33.370 --> 37:39.870 And then you can use this other application where you already have a 37:39.870 --> 37:45.410 certain level of security that you normally say is sufficient for bank 37:45.410 --> 37:46.030 transactions. 37:46.030 --> 37:51.130 This is just integrated into the merchant's software. 37:52.430 --> 38:00.390 And this way, you have just avoided to create a new payment interface. 38:00.870 --> 38:10.070 You just use the existing home banking software for executing such a 38:10.070 --> 38:10.370 payment. 38:10.370 --> 38:14.670 Certainly, we have here some clearing point again, and the customer 38:14.670 --> 38:17.590 bank, merchant bank, which have to communicate. 38:19.010 --> 38:24.110 So, you have your home banking software, which will send information 38:24.110 --> 38:26.690 from your bank to the merchant's bank. 38:27.550 --> 38:36.010 And the merchant then will deliver, as soon as you have sent the 38:36.010 --> 38:41.390 transfer statement, the merchant will actually send you the product. 38:42.470 --> 38:46.850 So, the interesting idea is that here you just integrate an existing 38:46.850 --> 38:50.910 system into another system to get the service. 38:51.790 --> 38:55.110 So, this is an interesting idea. 38:55.610 --> 38:58.970 They have all kinds of systems here. 38:58.970 --> 39:02.810 If you are interested in their products, just go to their pages. 39:03.350 --> 39:11.430 They have nice tutorials or descriptions of their products for 39:11.430 --> 39:12.230 payment. 39:15.510 --> 39:22.730 I would like to come to the final part of money that is different. 39:22.730 --> 39:27.970 What we talked about so far was using credit cards or using home 39:27.970 --> 39:29.270 banking on the last slide. 39:29.830 --> 39:33.250 And now I want to show you a concept that is also very interesting. 39:33.850 --> 39:40.530 A concept to actually generate real electronic money on a computer. 39:41.630 --> 39:46.570 So, if we talk about credit cards or home banking, we don't talk about 39:46.570 --> 39:46.910 cash. 39:47.350 --> 39:49.310 We don't talk about electronic money. 39:49.310 --> 39:54.950 We talk about using payment services that are available anyway. 39:56.050 --> 40:01.130 And so here, in eCash, we would like to get a new currency. 40:02.550 --> 40:10.070 In this new currency, every coin, so every unit of value there, exists 40:10.070 --> 40:10.770 as a file. 40:12.170 --> 40:16.170 Which immediately means you can make as many copies of those files as 40:16.170 --> 40:16.590 you like. 40:16.590 --> 40:20.750 And you have to make sure that this is detected and does not lead to 40:20.750 --> 40:22.930 unwanted duplication of values. 40:24.030 --> 40:27.190 And it is independent of other existing systems. 40:28.750 --> 40:33.090 So, this may be an advantage, may be a disadvantage, because it's a 40:33.090 --> 40:33.790 new system. 40:34.110 --> 40:36.410 If you want to use that, you have to install something new. 40:38.130 --> 40:41.490 It is a completely anonymous system, which certainly is important. 40:41.490 --> 40:49.570 We saw in SET, this was partially anonymous, but normal credit card 40:49.570 --> 40:51.650 systems are certainly not anonymous. 40:51.930 --> 40:53.570 But you can trace everything. 40:54.750 --> 40:57.710 It is an online solution, so it's not an open loop system. 40:58.490 --> 41:03.310 You need to check the validity of the files that you provide for 41:03.310 --> 41:03.770 payment. 41:04.270 --> 41:05.730 And we will see how that works. 41:06.530 --> 41:11.430 And, as I said, the value is represented as an electronic coin. 41:12.010 --> 41:15.710 And it uses, again, these encryption schemes. 41:15.810 --> 41:17.970 In this case, RSA, public key encryption. 41:18.710 --> 41:23.670 And another type of signature is so-called blind digital signature. 41:24.550 --> 41:26.230 This is the important concept. 41:26.970 --> 41:29.450 That's the reason why I would like to present this to you. 41:30.210 --> 41:38.030 eCash is not that popular at the moment, but it is a very interesting 41:38.030 --> 41:38.570 system. 41:39.010 --> 41:43.910 And I think it's just worthwhile to look at that concept, to see how 41:43.910 --> 41:46.490 we can actually perform a blind signature. 41:47.850 --> 41:49.910 So, what are the components of eCash? 41:49.990 --> 41:51.630 It is a closed loop system. 41:52.230 --> 41:56.370 We have the bank, we have the customer, and we have a merchant, which 41:56.370 --> 41:57.510 accepts eCash. 41:57.510 --> 42:03.150 So, the bank will issue electronic coins and change real money into 42:03.150 --> 42:03.630 eCash. 42:04.830 --> 42:08.430 And it certainly will also do the opposite. 42:08.690 --> 42:12.130 If you provide eCash to the bank, you will get real money back. 42:12.830 --> 42:18.170 The customer has an account at some eCash bank, where he can withdraw 42:18.170 --> 42:21.410 eCash and he can deposit eCash. 42:22.210 --> 42:27.570 And the merchants accept eCash and certainly also will have to change 42:27.570 --> 42:29.010 eCash into real money. 42:29.330 --> 42:30.510 We have to see how that works. 42:32.030 --> 42:36.390 The important point is how you actually generate electronic coins. 42:41.630 --> 42:48.450 So, the customer software, so-called cyber wallet, is able to generate 42:48.450 --> 42:49.170 money. 42:49.170 --> 42:50.170 That's perfect. 42:50.530 --> 42:51.910 A wallet which generates money. 42:52.910 --> 42:57.590 So, what do you do in order to generate money? 42:57.710 --> 43:00.810 You generate a random serial number. 43:01.410 --> 43:08.310 So, in every customer, if you want to get new money, you generate a 43:08.310 --> 43:12.910 random serial number, which has to be sufficiently long to guarantee 43:12.910 --> 43:13.470 uniqueness. 43:13.470 --> 43:18.930 If you have a sufficient number of bits, the probability of having 43:18.930 --> 43:23.530 duplicates is just negligibly small. 43:24.990 --> 43:30.890 And now, you fix for every serial number the desired coin value. 43:32.810 --> 43:37.210 So, you say, okay, I would like to have... with this serial number, I 43:37.210 --> 43:38.970 would like to get 5 Euro. 43:39.430 --> 43:41.610 That should be 100 Euro or whatever. 43:41.610 --> 43:46.290 So, the value that you would like to get certainly is up to you, or 43:46.290 --> 43:50.930 there will be some standard values that you can actually try to get. 43:53.270 --> 43:59.330 Now, you send the serial numbers and the coin values to the bank. 44:00.370 --> 44:05.910 You ask the bank to validate that this serial number is associated 44:05.910 --> 44:07.590 with the requested value. 44:07.890 --> 44:08.970 5 Euro, for example. 44:08.970 --> 44:14.850 But you do that by sending everything in a hidden envelope. 44:17.770 --> 44:23.490 Now, how can the bank validate a hidden serial number? 44:24.910 --> 44:26.350 That's the major point. 44:27.030 --> 44:32.850 You need a signature on a serial number and a value, but the bank 44:32.850 --> 44:37.350 should not know the value of that serial number. 44:37.350 --> 44:43.510 It should only know that it has validated a serial number with a 44:43.510 --> 44:47.710 certain value, and it deducts that value from the customer's account, 44:48.430 --> 44:50.470 and then sends back this information. 44:52.790 --> 44:59.190 So, the issuing bank validates the coins by its value-specific blind 44:59.190 --> 44:59.670 signature. 44:59.890 --> 45:06.030 So, it has different signature keys for the different values, and 45:06.030 --> 45:08.050 performs a blind signature. 45:08.870 --> 45:13.510 It is essentially a digital signature, but it is a blind signature. 45:14.030 --> 45:22.650 The bank does not know what is inside the envelope that is around the 45:22.650 --> 45:23.310 hidden number. 45:25.050 --> 45:29.310 It deducts the corresponding amount from the customer's account, and 45:29.310 --> 45:31.810 it sends the validated coins back to the customer. 45:31.810 --> 45:37.790 Something like a blind envelope is known to you. 45:38.050 --> 45:44.490 Sometimes you get an envelope where you have some carbonated, some 45:44.490 --> 45:48.050 black material inside, and you can sign on that. 45:49.090 --> 45:53.450 You could send back that envelope, and somebody who gets that envelope 45:53.450 --> 45:58.150 can open it, and take the piece of paper that is inside, and on that 45:58.150 --> 46:00.130 piece of paper you would have your signature. 46:01.290 --> 46:03.990 Or you didn't see the contents of that envelope. 46:04.610 --> 46:07.010 So, that's the blind signature. 46:07.810 --> 46:13.470 Now, we have to see how that is done using arithmetic. 46:14.490 --> 46:20.530 RSA is arithmetic, it's just taking numbers to a certain power, and 46:20.530 --> 46:24.730 this has to be done, or has to be used here. 46:24.830 --> 46:29.190 So, as I said, this blind signature is performed. 46:29.190 --> 46:34.310 The money is deducted, and then the validated coin is sent back to the 46:34.310 --> 46:34.690 customer. 46:35.910 --> 46:41.430 Now, the customer software will make the serial number visible again, 46:42.790 --> 46:47.810 and certainly also together with the digital signature. 46:48.590 --> 46:54.630 And now this serial number with the digital signature, and the 46:54.630 --> 46:59.710 certificate from the bank about the type of signature that it made. 46:59.850 --> 47:02.670 There is a statement on the value that is associated with that 47:02.670 --> 47:03.050 signature. 47:03.950 --> 47:08.530 Now, this combination of serial number and signature is the electronic 47:08.530 --> 47:08.970 coin. 47:10.030 --> 47:13.810 It has been validated by the bank, so you can use it. 47:16.560 --> 47:18.280 So, how do you actually do that? 47:19.340 --> 47:26.720 If Alice wants to hide, or Alice wants to get a certain message signed 47:26.720 --> 47:32.520 by Bob, but Bob should not know the contents of the message. 47:32.980 --> 47:34.060 He should only sign it. 47:35.160 --> 47:36.740 Sometimes you need things like that. 47:37.480 --> 47:43.540 So, you hide M in this blinding envelope, and Bob signs the envelope, 47:43.540 --> 47:49.560 and then Alice takes the signed message from the envelope. 47:50.600 --> 47:54.640 Very simply done if you have paper and envelopes. 47:55.500 --> 48:02.520 Now, in order to do that in the computer, you need your keys. 48:02.860 --> 48:10.480 So, you have your public and private keys, and Alice chooses a random 48:10.480 --> 48:15.680 number R, which is prime with respect to N. 48:18.380 --> 48:28.380 So, you have this value R, and then you compute R to the C times M. 48:30.600 --> 48:32.320 R to the C times M. 48:32.360 --> 48:33.480 So, M is the message. 48:34.560 --> 48:39.440 So, what Alice sends to Bob is R to the C times M, modulo N. 48:42.080 --> 48:43.280 This is M prime. 48:45.160 --> 48:51.820 So, here we assume that M is smaller than N. 48:53.620 --> 48:59.420 If it's larger than N, you certainly can do that with several pieces 48:59.420 --> 49:00.340 of that message. 49:00.340 --> 49:04.460 Now, Bob will sign M prime. 49:06.340 --> 49:10.400 Here, signing just means to use your secret key. 49:11.600 --> 49:15.720 So, Bob uses his secret key on this message. 49:16.640 --> 49:25.140 Now, as you saw here, Alice used the public key of Bob. 49:26.050 --> 49:29.940 Now, Bob uses his secret key on M prime. 49:30.280 --> 49:32.240 M prime to the D, modulo N. 49:33.260 --> 49:40.580 But M prime to the D is, as M prime is R to the C times M, this is R 49:40.580 --> 49:44.800 to the C times M to the D, modulo N. 49:44.900 --> 49:50.680 Now, if you use arithmetic here, you see this is R to the C times D 49:50.680 --> 49:52.960 times M, modulo N. 49:52.960 --> 50:01.700 And we know from the RSA algorithm that R to the C times D is R. 50:02.600 --> 50:09.580 So, what Alice gets back is R times M to the D. 50:11.360 --> 50:16.640 Only M is taken to the power of D, so this is encrypted using the 50:16.640 --> 50:18.500 secret key of Bob. 50:19.320 --> 50:24.860 And now Alice, since she knows the random number, just has to multiply 50:24.860 --> 50:28.640 this R to the minus 1, has to divide by R. 50:30.860 --> 50:34.520 And then, what you get is M to the D, modulo N. 50:35.600 --> 50:39.900 And M to the D, modulo N is the signature of Bob. 50:41.160 --> 50:48.680 Because everybody else can use Bob's public key in order to retrieve 50:48.680 --> 50:49.620 the value M. 50:50.160 --> 50:56.500 M is the serial number, and so if you want to check whether that has 50:56.500 --> 51:02.280 been signed by a bank, you just need to use the bank's public key, and 51:02.280 --> 51:07.820 you can check whether the serial number on the coin is actually the 51:07.820 --> 51:11.020 serial number that has been signed by the bank. 51:11.520 --> 51:15.180 So, this is the way we actually perform a blind signature. 51:15.960 --> 51:21.800 Modify the value of blinding it by multiplying it with a random number 51:21.800 --> 51:27.460 taken to the appropriate power, such that if it is encrypted again, 51:27.860 --> 51:29.900 you get this R back. 51:29.900 --> 51:37.680 But, certainly Bob has no chance to actually retrieve R, because he 51:37.680 --> 51:41.120 cannot factorize this number. 51:41.240 --> 51:45.020 He cannot retrieve from R times M to the D, he cannot retrieve R. 51:46.360 --> 51:47.500 This is not possible. 51:49.100 --> 51:56.420 At least with reasonable effort, it's not possible. 51:57.680 --> 52:02.820 So, only Bob could generate the signature, although he did not sign it 52:02.820 --> 52:08.080 exactly, but he signed M', and any other person can verify that Bob 52:08.080 --> 52:13.180 actually used his secret key to produce M to the D. 52:14.580 --> 52:17.440 So, this is the blind signature. 52:18.440 --> 52:28.100 Now we can look at the procedure to generate electronic coins again. 52:28.760 --> 52:35.340 Here we have, again, the customer blinds the serial numbers of the 52:35.340 --> 52:35.840 coins. 52:36.400 --> 52:43.760 Here, visualized as an envelope, he sends the serial number in this 52:43.760 --> 52:44.960 envelope to the bank. 52:46.360 --> 52:50.020 And certainly this can also be encrypted with the bank's public key, 52:50.440 --> 52:52.820 in order to make this communication more secure. 52:54.340 --> 52:59.800 And so here you have this message, which is then sent to the bank. 53:01.120 --> 53:05.760 And the bank validates everything, as stated here, the bank verifies 53:05.760 --> 53:13.540 the customer's signature, signs the coins, and deducts the money, and 53:13.540 --> 53:18.220 then returns the validated blinded coins to the customer. 53:20.500 --> 53:25.500 Again, in a secure way, so the bank should use the public key of the 53:25.500 --> 53:30.220 customer, because certainly everybody else would be interested in 53:30.220 --> 53:34.100 getting such a validated coin. 53:36.060 --> 53:41.620 And then the customer can use his or her private key to decrypt the 53:41.620 --> 53:43.860 message and remove the blinding factor. 53:44.900 --> 53:50.680 And so, a coin, an electronic coin, consists of the serial number, the 53:50.680 --> 53:57.740 bank's signature, and the bank's certificate, stating the amount of 53:57.740 --> 53:59.400 money that is in that coin. 54:00.320 --> 54:06.340 So that's this electronic coin, just a bit of information, but 54:06.340 --> 54:10.640 validated by the bank, and the bank does not know the serial numbers 54:10.640 --> 54:11.400 that is validated. 54:13.600 --> 54:19.780 So in that way, the customer can use the serial numbers, and the bank 54:19.780 --> 54:27.120 does not know who actually used these serial numbers, because the bank 54:27.120 --> 54:36.000 had no chance of actually storing these serial numbers, because they 54:36.000 --> 54:37.120 were not known to the bank. 54:38.620 --> 54:45.960 But if you go shopping with eCash, what you do is, the customer goes 54:45.960 --> 54:52.220 to the merchant, or the merchant sends a payment request you have to 54:52.220 --> 54:56.740 pay, and then the customer sends his coins. 54:57.800 --> 55:02.680 But for that, the merchant who accepts eCash certainly has to check 55:02.680 --> 55:09.280 whether these coins are valid, so he will send this coin to the eCash 55:09.280 --> 55:09.740 bank. 55:10.360 --> 55:12.380 The eCash bank now can do the following. 55:12.520 --> 55:17.920 The eCash bank can check whether this serial number actually has been 55:17.920 --> 55:18.740 used before. 55:19.440 --> 55:24.660 Now if somebody else handed in that serial number before, it says, 55:24.860 --> 55:30.300 okay, this has already been used, and this is invalidated. 55:31.260 --> 55:35.520 But if it's verified, the money is just sent back. 55:36.700 --> 55:42.620 So if this coin has not been used before, the money will be 55:42.620 --> 55:48.520 transferred to the merchant's account, and so the verification tells 55:48.520 --> 55:56.300 the merchant that he got real money, and he will provide the product 55:56.300 --> 55:57.200 to the customer. 55:58.260 --> 56:02.740 So, you see we have this closed-loop system. 56:02.900 --> 56:08.240 The merchant needs to perform this online checking, and as soon as you 56:08.240 --> 56:11.720 have done this online checking, the coin is invalidated. 56:16.660 --> 56:22.060 So the receipt is sent to the customer, and then for verification, the 56:22.060 --> 56:26.900 bank stores all the serial numbers of retrieved coins in the database, 56:27.520 --> 56:33.340 and so if the serial number is already there, this must be a false 56:33.340 --> 56:33.840 duplicate. 56:34.700 --> 56:37.500 And so you can only use every coin once. 56:38.240 --> 56:43.140 Certainly you could send or give that to a merchant, and the merchant 56:43.140 --> 56:48.100 might trust you and say, okay, I trust that this is just a single or a 56:48.100 --> 56:58.180 unique copy, but since it is too simple to make copies, it's just 56:58.180 --> 57:03.520 reasonable to check, and then you see that the possibility to actually 57:03.520 --> 57:09.400 exchange electronic money is restricted. 57:10.400 --> 57:17.740 Nevertheless, it is a way of producing electronic money, and the 57:17.740 --> 57:23.980 interesting point is that it provides anonymity to a level that is not 57:23.980 --> 57:26.460 present in other payment systems. 57:26.700 --> 57:29.000 It is certainly present in our cash system. 57:29.640 --> 57:35.720 If we use cash, nobody can know that I have used that cash. 57:35.720 --> 57:39.160 You cannot detect from the coin who has used that. 57:40.340 --> 57:42.040 That's the same with the e-cash. 57:42.340 --> 57:49.420 You cannot detect who actually has provided that e-cash coin to the 57:49.420 --> 57:49.780 merchant. 57:50.620 --> 57:54.120 There is no information on the customer available to the bank. 57:57.230 --> 57:59.930 Okay, evaluation of that. 57:59.930 --> 58:05.010 Transaction costs are low. 58:05.110 --> 58:12.790 It depends on the cost for communication, the fee that the bank 58:12.790 --> 58:16.770 charges for checking electronic coins. 58:17.370 --> 58:20.210 Security certainly is there by RSA encryption. 58:20.990 --> 58:24.890 Traceability is restricted because we have anonymity. 58:28.310 --> 58:32.330 If the merchant has sent a receipt, he must have got the money. 58:33.090 --> 58:34.810 So, you have undeniability of payment. 58:35.610 --> 58:39.190 And the user certainly can trace the coin. 58:39.350 --> 58:46.870 So, if the user has produced these coins, the user can certainly check 58:46.870 --> 58:50.330 whether the coin has been received by a bank. 58:50.330 --> 58:58.510 By just checking whether this serial number is sought by that bank. 58:58.930 --> 59:03.870 And then it would be possible for the user to check who actually used 59:03.870 --> 59:10.290 the coins or who made this transfer of e-coins, e-cash into real money 59:10.290 --> 59:10.910 again. 59:12.650 --> 59:15.190 Online checking certainly is necessary. 59:16.010 --> 59:23.950 Acceptability depends on where actually this is available. 59:25.210 --> 59:26.990 And the transferability. 59:27.710 --> 59:31.690 Well, you can certainly transfer your files to other persons, no 59:31.690 --> 59:32.110 problem. 59:32.690 --> 59:35.050 So, this transferability is quite simple here. 59:35.510 --> 59:39.170 But you always must make sure that the coin is still valid that you 59:39.170 --> 59:39.410 get. 59:40.670 --> 59:43.010 Divisibility certainly is poor. 59:43.490 --> 59:46.330 Here you have fixed amounts of money. 59:47.990 --> 59:52.950 So, if you have to pay a larger amount, you can do that. 59:53.030 --> 59:55.050 It depends on the coin values that you have. 01:00:00.230 --> 01:00:05.570 Digicash was the company which designed that. 01:00:05.730 --> 01:00:08.630 Actually, it was designed by David Chaum. 01:00:08.630 --> 01:00:12.630 He designed that protocol which led to this e-cash money. 01:00:13.550 --> 01:00:15.170 And several banks tried it out. 01:00:15.770 --> 01:00:21.670 The problem is that the banks are very cautious not to use that for 01:00:21.670 --> 01:00:22.810 large amounts of money. 01:00:23.270 --> 01:00:28.670 If you would allow to use e-cash for large amounts of money, you would 01:00:28.670 --> 01:00:31.450 have uncontrolled transfer of large amounts of money. 01:00:32.350 --> 01:00:34.210 And this is something the banks don't like. 01:00:34.210 --> 01:00:40.690 So, this was another reason why they actually did not use that to a 01:00:40.690 --> 01:00:41.550 large extent. 01:00:43.890 --> 01:00:49.250 So, we are mainly stuck with the credit card payments and home banking 01:00:49.250 --> 01:00:49.870 payments. 01:00:50.530 --> 01:00:52.150 And then there are smart cards available. 01:00:52.830 --> 01:00:58.250 So, this here is an example of a Mondex card. 01:00:58.250 --> 01:01:04.650 So, a certain terminal which can be used for payment transactions. 01:01:05.930 --> 01:01:11.770 You have your cards which you can use for paying in, like with a bank 01:01:11.770 --> 01:01:14.510 card you can pay in the tram or at other places. 01:01:15.310 --> 01:01:20.230 So, on smart cards we can actually deposit money. 01:01:21.650 --> 01:01:23.930 Certainly, normally it's a prepaid card. 01:01:23.930 --> 01:01:27.790 You have to deposit some money on your bank card in order to be able 01:01:27.790 --> 01:01:28.550 to pay something. 01:01:29.370 --> 01:01:33.870 This is not for usage on the Internet normally, unless you have a 01:01:33.870 --> 01:01:40.270 software that allows to pay with your smart card from your computer. 01:01:40.430 --> 01:01:42.910 But that is not the normal way this is used. 01:01:43.770 --> 01:01:50.270 It is designed to replace cash, but the extent to which this is 01:01:50.270 --> 01:01:51.770 successful is limited. 01:01:52.790 --> 01:01:57.110 Who of you has a money card or has money on his bank card? 01:01:59.050 --> 01:02:00.130 Just very few. 01:02:00.770 --> 01:02:00.950 Okay. 01:02:01.690 --> 01:02:05.790 So, some people like to use these electronic things, others don't. 01:02:07.190 --> 01:02:13.150 It is quite comfortable if you want to ride on the tram. 01:02:13.230 --> 01:02:15.810 You don't have the cash available to pay. 01:02:16.230 --> 01:02:17.690 You can use it with your bank card. 01:02:18.630 --> 01:02:19.270 Okay. 01:02:19.930 --> 01:02:25.470 On a smart card we have this small processor with a bit of memory. 01:02:26.230 --> 01:02:30.570 There are standard architectures, some standard processors and memory 01:02:30.570 --> 01:02:31.150 on there. 01:02:31.690 --> 01:02:34.670 Storage areas, secure storage areas and others. 01:02:36.350 --> 01:02:39.950 I will not go into the details of smart card technology here. 01:02:39.950 --> 01:02:46.770 I just wanted to mention that that is another way of paying in an 01:02:46.770 --> 01:02:47.730 electronic way. 01:02:49.290 --> 01:02:55.690 The advantage of a standard bank card is that you have improved 01:02:55.690 --> 01:02:56.670 security. 01:02:56.930 --> 01:03:00.910 If you have this smart card with this processor, you can have a 01:03:00.910 --> 01:03:02.590 private key stored in there. 01:03:02.590 --> 01:03:06.690 You have a larger memory than a normal magnetic card. 01:03:06.930 --> 01:03:14.350 And you can really use authentication with these smart cards. 01:03:14.710 --> 01:03:18.310 The problem is that if you look at initial versions of smart cards, 01:03:18.450 --> 01:03:20.150 there were several attacks. 01:03:20.330 --> 01:03:25.710 I mentioned those when I presented to you the cryptographic algorithms 01:03:25.710 --> 01:03:33.790 like this attack where you would just measure the power usage and from 01:03:33.790 --> 01:03:39.510 that detect the values of the private keys. 01:03:42.430 --> 01:03:47.410 These smart cards are certainly also used in these home banking 01:03:47.410 --> 01:03:49.790 computer interfaces. 01:03:50.510 --> 01:03:53.470 There is a successor to that, meanwhile, which is no longer called 01:03:53.470 --> 01:03:54.590 HPCI anymore. 01:03:54.590 --> 01:03:57.590 I should have put it in here. 01:03:57.650 --> 01:04:01.170 I didn't, but if you go to this website, you will get the information 01:04:01.170 --> 01:04:05.570 on the new standard that is an extended version of that home banking 01:04:05.570 --> 01:04:06.690 computer interface. 01:04:08.330 --> 01:04:13.630 Okay, and then there is a product by Thun again. 01:04:14.810 --> 01:04:19.530 SmartPay payment systems using your smart card. 01:04:19.530 --> 01:04:24.150 They meanwhile have also things like PhonePay, which is also an 01:04:24.150 --> 01:04:28.190 interesting concept to use your mobile phone for payment purposes. 01:04:29.390 --> 01:04:33.490 And you know that your mobile phone communication is done in a secure 01:04:33.490 --> 01:04:33.930 way. 01:04:34.450 --> 01:04:38.710 You are authenticated as a user of the mobile phone and this 01:04:38.710 --> 01:04:42.970 authentication mechanism can be used to produce secure payment 01:04:42.970 --> 01:04:43.750 systems. 01:04:45.150 --> 01:04:49.110 We have certain standards for electronic purses. 01:04:50.610 --> 01:04:59.330 So, there is a European standard for inter-sector electronic purse 01:04:59.330 --> 01:05:04.510 system where you have all kinds of specifications for different 01:05:04.510 --> 01:05:08.650 operations that have to be performed on these electronic purses. 01:05:08.650 --> 01:05:13.190 You must be able to load money, to load an amount on such an 01:05:13.190 --> 01:05:14.890 electronic purse. 01:05:15.310 --> 01:05:18.770 You must be able to purchase something, that means deduct a certain 01:05:18.770 --> 01:05:21.370 amount of money from that value. 01:05:22.050 --> 01:05:25.710 You must be able to do an incremental purchase. 01:05:26.130 --> 01:05:30.330 So, certainly you have several steps to do a purchase. 01:05:32.350 --> 01:05:35.310 You want to buy several things. 01:05:35.310 --> 01:05:40.710 Then it must be possible to also have a reverse of the purchase. 01:05:40.870 --> 01:05:46.810 If you would like to invalidate a purchase, the spending of money, it 01:05:46.810 --> 01:05:50.550 must be possible to retrieve that, to revalidate that money. 01:05:51.910 --> 01:05:55.590 Then you have something that cancels last purchase and also a currency 01:05:55.590 --> 01:05:56.190 exchange. 01:05:56.490 --> 01:06:00.170 So, if you go with your smart card to another country where there is a 01:06:00.170 --> 01:06:03.510 different currency, certainly the value on your smart card should 01:06:03.510 --> 01:06:04.970 adjust to the new currency. 01:06:05.270 --> 01:06:09.250 So, you need this currency exchange operation on there. 01:06:09.950 --> 01:06:14.210 So, this is a very long specification of all these operations. 01:06:15.150 --> 01:06:22.030 And it's just done to provide a sufficient level of security for the 01:06:22.030 --> 01:06:24.070 holders of such a smart card. 01:06:27.090 --> 01:06:35.710 Then, there is a system called Paybox, where you pay a certain amount 01:06:35.710 --> 01:06:37.750 at some Paybox accepting shop. 01:06:37.910 --> 01:06:42.710 So, this is an electronic system working over the World Wide Web. 01:06:43.790 --> 01:06:49.770 You pay a certain amount and then the customer provides their mobile 01:06:49.770 --> 01:06:53.290 phone number or some reference number to the merchant. 01:06:53.290 --> 01:06:58.410 And the merchant forwards this number, the Paybox identification 01:06:58.410 --> 01:07:06.570 number and the amount to be paid to the Paybox clearing service. 01:07:06.770 --> 01:07:12.430 So, you can use essentially your mobile phone for paying. 01:07:12.790 --> 01:07:13.830 And how does this work now? 01:07:13.910 --> 01:07:20.030 The clearing service calls the customer at his mobile phone. 01:07:20.890 --> 01:07:26.430 So, the merchant sends this request to this clearing service. 01:07:26.630 --> 01:07:29.690 The clearing service calls the customer on his mobile phone. 01:07:30.310 --> 01:07:33.350 And so, this is authenticated immediately. 01:07:34.230 --> 01:07:38.990 And so, the customer can now confirm that he would like to actually 01:07:38.990 --> 01:07:39.930 pay this amount. 01:07:40.670 --> 01:07:44.530 And so, the merchant sees that this has been paid. 01:07:44.530 --> 01:07:51.570 And then this clearing service deducts the payment amount from the 01:07:51.570 --> 01:07:52.430 customer's account. 01:07:53.310 --> 01:07:57.070 So, this is now a payment service using a mobile phone. 01:07:57.530 --> 01:08:01.090 It certainly is not anonymous because the name of the merchant is 01:08:01.090 --> 01:08:01.870 included there. 01:08:03.770 --> 01:08:11.630 And so, it's certainly not as anonymous as the eCash, but it's another 01:08:11.630 --> 01:08:12.730 interesting system. 01:08:12.730 --> 01:08:19.370 As you saw, most of the payment systems that I showed to you were not 01:08:19.370 --> 01:08:19.730 anonymous. 01:08:20.450 --> 01:08:25.710 But this is just very hard to get an electronic system that provides 01:08:25.710 --> 01:08:27.430 anonymity as one would like it. 01:08:29.350 --> 01:08:35.770 Here, I have just displayed several possibilities for using payment 01:08:35.770 --> 01:08:37.510 architectures in a secure way. 01:08:37.510 --> 01:08:45.370 If you put everything in software on your computer, secret key plus 01:08:45.370 --> 01:08:52.510 perform all the computations and the protocols, then certainly this 01:08:52.510 --> 01:08:58.390 computer may be vulnerable to Trojan horses or viruses or things like 01:08:58.390 --> 01:08:58.770 that. 01:08:58.770 --> 01:09:07.850 And so, this information can be compromised. 01:09:11.650 --> 01:09:20.130 And so, if the user is just using his local PC, there is some danger 01:09:20.130 --> 01:09:21.210 of being attacked. 01:09:21.210 --> 01:09:24.430 Then, you could use a smart card. 01:09:24.870 --> 01:09:27.050 Then, you have the secret key on your smart card. 01:09:27.170 --> 01:09:31.730 At least, some level of security and some secret key computation is 01:09:31.730 --> 01:09:33.290 performed here on the smart card. 01:09:33.810 --> 01:09:42.970 Protocols are still on this PC and the user uses that PC. 01:09:42.970 --> 01:09:48.710 And then, you might have user devices, secret key computation 01:09:48.710 --> 01:09:52.930 protocols all done on a special device and not on this PC. 01:09:53.290 --> 01:09:58.630 So, the point of this slide is that one must make sure that the 01:09:58.630 --> 01:10:04.010 devices that are used for performing things like digital signatures 01:10:04.010 --> 01:10:09.010 and things like that should be secure, should be certified to be 01:10:09.010 --> 01:10:09.510 secure. 01:10:09.510 --> 01:10:12.710 And for that, you need special devices. 01:10:13.690 --> 01:10:15.430 Then, you have the highest level of security. 01:10:15.950 --> 01:10:22.010 If you just use your standard computer for these things, then this 01:10:22.010 --> 01:10:23.930 might be vulnerable to attacks. 01:10:24.110 --> 01:10:27.470 And so, you don't have the level of security that you actually would 01:10:27.470 --> 01:10:28.150 like to have. 01:10:29.410 --> 01:10:36.790 Okay, this was a survey of all kinds of electronic payment systems. 01:10:36.790 --> 01:10:43.250 Here in this table, I have a listing of different systems. 01:10:43.410 --> 01:10:46.950 Here you see eCash, which is an online payment system. 01:10:47.350 --> 01:10:48.590 It is untraceable. 01:10:48.970 --> 01:10:49.630 It is anonymous. 01:10:50.410 --> 01:10:55.050 You see there are other systems around which provide all kinds of 01:10:55.050 --> 01:10:56.390 different payment services. 01:10:57.490 --> 01:11:00.630 I don't want to go into the details of all these. 01:11:00.770 --> 01:11:03.210 I've shown you SET. 01:11:04.030 --> 01:11:08.570 I did not show you most of the other things here. 01:11:08.750 --> 01:11:10.230 I showed you eCash. 01:11:11.210 --> 01:11:14.570 And I would like to end the lecture today. 01:11:15.150 --> 01:11:16.650 I can almost not speak anymore. 01:11:17.430 --> 01:11:19.750 And next week, we have the last lecture. 01:11:20.770 --> 01:11:28.810 And next week, I will show you then something about firewalls that 01:11:28.810 --> 01:11:31.530 will be the last lecture of this course. 01:11:31.750 --> 01:11:32.670 Thank you for your attention.