WEBVTT

00:26.170 --> 00:27.430
Good morning.

00:27.750 --> 00:30.670
Welcome to another session on algorithms for Internet applications.

00:32.230 --> 00:36.410
Last week we didn't get too far because of the technical problems.

00:36.590 --> 00:38.070
This week we start in time.

00:39.010 --> 00:47.970
And last week we looked at the protocol for secure transfer of

00:47.970 --> 00:52.250
payments using credit card systems, secure electronic transactions, a

00:52.250 --> 00:56.590
protocol developed by the leading credit card companies, certainly IBM

00:56.590 --> 00:59.690
is not a credit card company, but Visa and MasterCard are.

01:00.510 --> 01:07.350
And the major properties that we looked at are confidentiality of

01:07.350 --> 01:11.370
information, data integrity and authentication, something which is

01:11.370 --> 01:17.510
only partially realized in the paper-based credit card payment system.

01:17.690 --> 01:23.470
But in the digital version, the requirements are harder than for the

01:23.470 --> 01:24.370
paper -based version.

01:24.370 --> 01:27.670
And in particular, the confidentiality is something which you don't

01:27.670 --> 01:31.850
have in the paper-based credit card systems.

01:32.910 --> 01:35.390
And we look at the ways how this is achieved.

01:35.490 --> 01:41.290
We briefly look at this control flow for the SET system.

01:42.030 --> 01:48.470
And this was one important slide because it shows one of the major

01:48.470 --> 01:53.030
ideas that are in this SET protocol.

01:53.030 --> 01:59.370
This separation of information into two parts.

02:00.370 --> 02:06.910
One part, the order information, the information that the customer has

02:06.910 --> 02:11.850
to send to the merchant in order to tell him what she wants to buy.

02:12.210 --> 02:16.490
And the other part is the payment information containing the

02:16.490 --> 02:19.910
information that is relevant for the bank, but certainly not for the

02:19.910 --> 02:20.250
merchant.

02:20.570 --> 02:25.430
And therefore, this payment information is sent to the merchant only

02:25.430 --> 02:26.490
in encrypted form.

02:26.870 --> 02:33.550
And only the bank will later on be capable of decrypting this message.

02:33.550 --> 02:39.470
And the major part then is this way of signing this combined message

02:39.470 --> 02:46.850
by computing the digests of the two parts of this information.

02:47.130 --> 02:49.930
A digest of the order information and a digest of the payment

02:49.930 --> 02:50.470
information.

02:50.470 --> 02:54.670
And then we have a combined digest of both.

02:55.090 --> 03:02.130
And it's an encryption of this combined digest using the customer's

03:02.130 --> 03:03.130
private key.

03:03.750 --> 03:08.390
And so this dual signature is one of the major ingredients providing

03:08.390 --> 03:14.290
the confidentiality that was required in the specification of this

03:14.290 --> 03:15.110
protocol.

03:15.110 --> 03:24.410
And we started to look at the individual or the transactions that we

03:24.410 --> 03:24.970
have there.

03:25.270 --> 03:29.030
So the first was the initiate request, then we get the initiate

03:29.030 --> 03:29.790
response.

03:32.230 --> 03:38.510
This is containing information that the customer needs in order to be

03:38.510 --> 03:42.990
capable of actually computing this dual signature.

03:46.170 --> 03:52.070
And also to compute the payment information in an encrypted way such

03:52.070 --> 03:57.230
that the bank can or is the only institution that can read this.

03:57.830 --> 04:05.570
And we will look now again into these steps of the SET protocol.

04:06.270 --> 04:14.050
So this was the initial response of the merchant containing the signed

04:14.050 --> 04:17.150
information that the customer needs.

04:17.270 --> 04:20.270
So we have the digital signature of the merchant.

04:20.510 --> 04:25.930
The merchant has, as every partner in this protocol, two key pairs.

04:26.610 --> 04:32.730
It's a signature key and key exchange key pair.

04:32.730 --> 04:39.810
So since the merchant signed this initial message here, she has to

04:39.810 --> 04:47.230
send the public key of this signature key pair to the cardholder.

04:48.170 --> 04:55.690
And the merchant also has to send the public key of the payment

04:55.690 --> 04:58.250
gateways exchange key pair.

04:58.250 --> 05:04.310
So these two certificates are sent to the cardholder and the

05:04.310 --> 05:07.430
cardholder after that will receive.

05:07.710 --> 05:15.950
This can verify the integrity of the initial information by retrieving

05:15.950 --> 05:18.110
the merchant's public key.

05:18.810 --> 05:21.590
As we can see here...

05:21.590 --> 05:28.370
Oops, I should get the pen.

05:30.610 --> 05:32.030
Now we are back at the slide.

05:32.230 --> 05:35.470
So here we have the verification of the signature.

05:36.150 --> 05:45.750
And the payment gateways public key is needed in the second step when

05:45.750 --> 05:51.930
the cardholder compiles or constructs the purchase order.

05:51.930 --> 05:57.290
So the purchase order, as we have seen, is split into two parts.

05:57.930 --> 06:02.770
The order information and the payment information.

06:03.370 --> 06:10.790
And both parts are compacted into these message digests.

06:11.050 --> 06:14.310
The order information digest, the payment information message digest,

06:14.450 --> 06:17.430
both are combined into the combined digest.

06:17.430 --> 06:24.010
And then this is encrypted using the cardholder's private signature

06:24.010 --> 06:24.710
key.

06:25.010 --> 06:29.490
And this then results in the dual signature as we have seen on the

06:29.490 --> 06:30.950
previous slides.

06:31.990 --> 06:39.790
Now this dual signature is combined with the payment information.

06:39.790 --> 06:46.050
So the payment information and the dual signature both are combined

06:46.050 --> 06:47.710
and are encrypted.

06:48.830 --> 06:54.470
Encrypted using just one session key that is generated just for this

06:54.470 --> 06:54.890
purpose.

06:55.850 --> 07:00.710
And so we have here the encrypted payment message.

07:01.330 --> 07:05.070
Now it's just the payment information plus the dual signature.

07:05.070 --> 07:09.870
Now the dual signature can only serve its purpose if there is

07:09.870 --> 07:14.070
something more that the bank later on can look at.

07:14.070 --> 07:25.730
So the bank will be able to compute its own payment information

07:25.730 --> 07:26.590
message digest.

07:26.970 --> 07:32.310
Since the bank will later on encrypt or decrypt this encrypted payment

07:32.310 --> 07:32.950
information.

07:34.890 --> 07:40.790
But the merchant will not have access to the payment information.

07:40.790 --> 07:47.150
Therefore, the digest of the payment information has to be sent

07:47.150 --> 07:49.090
separately to the merchant.

07:49.490 --> 07:51.830
We will see later on how the merchant will use this.

07:52.730 --> 07:55.950
So this is the payment information message digest.

07:56.770 --> 08:00.030
And what else does the cardholder include?

08:00.470 --> 08:05.790
Certainly the order information has to be included.

08:05.790 --> 08:09.930
The merchant must know what the cardholder wants to buy.

08:11.030 --> 08:20.250
And the dual signature is also sent to the merchant in exactly the way

08:20.250 --> 08:23.130
that it was generated above here.

08:24.310 --> 08:29.510
And then we have here something called the payment digital envelope.

08:29.510 --> 08:35.270
So in some sense, we could call this an envelope because we have to

08:35.270 --> 08:40.350
get access to this in order to be able to get access to all the

08:40.350 --> 08:41.790
remaining parts.

08:43.250 --> 08:46.090
And so what is included here?

08:46.350 --> 08:51.390
This payment digital envelope is consisting of or is an encrypted

08:51.390 --> 08:57.810
version of the symmetric key.

08:59.330 --> 09:03.950
So this is the payment digital envelope is something which the payment

09:03.950 --> 09:09.870
gateway will need in order to get access to this encrypted payment

09:09.870 --> 09:10.350
message.

09:10.350 --> 09:12.990
This payment message was encrypted using this symmetric key.

09:13.390 --> 09:22.090
So this symmetric key here has to be encrypted using the payment

09:22.090 --> 09:24.910
gateway's public key exchange key.

09:25.450 --> 09:31.030
So the public key of the payment gateway is used now to encrypt this

09:31.030 --> 09:31.970
symmetric key.

09:31.970 --> 09:43.470
And also some account data is added to this payment digital envelope.

09:43.910 --> 09:49.630
So symmetric key plus account data are encrypted using this public key

09:49.630 --> 09:50.310
exchange key.

09:51.310 --> 09:57.450
And that means that this information here, the payment digital

09:57.450 --> 10:06.930
envelope plus the encrypted payment message, is something which the

10:06.930 --> 10:13.470
cardholder sends to the merchant, but it is destined for the payment

10:13.470 --> 10:14.150
gateway.

10:16.150 --> 10:22.050
The public key exchange key was available to the cardholder from the

10:22.050 --> 10:24.910
certificate that she got from the merchant.

10:25.910 --> 10:33.450
And then we have here the cardholder certificate for a signature key.

10:34.550 --> 10:40.870
And the signature key or this public key for the signature key pair

10:40.870 --> 10:47.250
certainly is necessary for the merchant to be able to verify the dual

10:47.250 --> 10:51.610
signature or to verify the integrity of the order information.

10:51.610 --> 10:55.950
And it is necessary for the payment gateway later on in order to be

10:55.950 --> 11:02.070
able to verify also the dual signature as we will see in a moment.

11:02.950 --> 11:07.190
Okay, so these are the ingredients of this message of this purchase

11:07.190 --> 11:07.670
order.

11:08.070 --> 11:12.010
So we have the order information in plain text as seen here.

11:12.010 --> 11:16.490
We have the encrypted payment information and we have the dual

11:16.490 --> 11:23.830
signature where the dual signature is also sent in encrypted form to

11:23.830 --> 11:25.210
the bank later on.

11:26.330 --> 11:30.510
Okay, the merchant will receive this information.

11:31.710 --> 11:37.290
It will verify the order information.

11:37.290 --> 11:44.030
It will not verify or the merchant will not verify the payment

11:44.030 --> 11:44.550
information.

11:44.690 --> 11:46.210
Certainly not because it cannot read it.

11:46.650 --> 11:52.810
But the merchant is interested in verifying that the order information

11:52.810 --> 11:53.450
is correct.

11:53.990 --> 11:55.030
That's not the only thing.

11:55.150 --> 11:57.970
The merchant also wants to know whether the payment information

11:57.970 --> 12:01.190
actually belongs to the order information.

12:01.190 --> 12:06.810
Otherwise, the customer would be or the cardholder would be capable of

12:06.810 --> 12:13.330
just saying, okay, I tell the merchant I want to buy something at a

12:13.330 --> 12:14.030
certain value.

12:14.630 --> 12:20.070
And to the bank, I just send payment information on a different value.

12:20.390 --> 12:25.450
And since the merchant doesn't see this payment information, she will

12:25.450 --> 12:29.270
not be able to notice that it's not the amount that actually had to be

12:29.270 --> 12:29.590
paid.

12:29.590 --> 12:34.130
So there could be messages in there which would not be related to each

12:34.130 --> 12:34.970
other.

12:35.310 --> 12:40.890
But here it is necessary or somebody else could interfere.

12:41.050 --> 12:45.250
So here it's just necessary to make sure that payment information and

12:45.250 --> 12:50.170
order information are related and that this dual signature actually

12:50.170 --> 12:51.190
belongs to both.

12:51.970 --> 13:00.050
So in order to do that, the cardholder computes the message digest

13:00.050 --> 13:03.450
from the order information.

13:03.890 --> 13:05.390
This is done here.

13:05.750 --> 13:09.910
So the cardholder gets the message digest for the order information.

13:11.230 --> 13:17.690
Then in the message of the cardholder included this message digest of

13:17.690 --> 13:18.690
the payment information.

13:18.690 --> 13:27.690
Now both can be combined and the merchant can compute the combined

13:27.690 --> 13:29.930
message digest from those two.

13:30.330 --> 13:35.490
So the combination of both leads to the combined message digest.

13:36.070 --> 13:41.490
And then the merchant can retrieve the cardholder's public signature

13:41.490 --> 13:43.470
key from the certificate.

13:45.710 --> 13:50.530
This public key is used to decrypt the dual signature.

13:51.210 --> 13:56.890
This results in the combined message digest that the cardholder

13:56.890 --> 13:58.670
computed and both can be compared.

13:59.110 --> 14:05.190
So here we have the standard verification of a signature modified

14:05.190 --> 14:07.490
slightly because we have this dual signature.

14:07.490 --> 14:13.950
Okay, this is the action on receipt of the purchase order at the

14:13.950 --> 14:19.430
merchant's site and then the merchant will have to respond.

14:20.370 --> 14:25.750
And so it's the next message sent from the merchant to the cardholder.

14:26.170 --> 14:29.310
What does the merchant include here?

14:29.310 --> 14:36.510
Some purchase response which is of no interest here because we here

14:36.510 --> 14:41.850
just look at the cryptographic properties of this protocol.

14:42.820 --> 14:49.150
So the purchase response information again is signed by the merchant.

14:51.750 --> 14:56.450
The digital signature is sent together with the purchase response.

14:57.350 --> 15:04.450
And certainly again the certificate, the merchant's certificate for

15:04.450 --> 15:08.070
its signature key is included in this message.

15:08.070 --> 15:14.010
So certificates that are needed to process the messages at the

15:14.010 --> 15:19.790
recipient's site are always included in these messages.

15:20.550 --> 15:26.090
Then we get again the receipt of the purchase response at the

15:26.090 --> 15:28.250
cardholder's site.

15:28.410 --> 15:30.830
So this is again at the cardholder's place here.

15:31.230 --> 15:34.550
The cardholder will again verify the purchase response.

15:34.550 --> 15:37.230
This is just the standard signature verification.

15:37.950 --> 15:43.250
The computation of the digest from the plain text here and then

15:43.250 --> 15:50.450
decryption of the digital signature and the comparison of the two

15:50.450 --> 15:52.770
pieces of information here.

15:52.850 --> 15:56.630
That's just standard verification of the digital signatures.

15:57.270 --> 16:00.970
Then we have the communication between merchant and payment gateway.

16:01.970 --> 16:09.410
And here again we have two flows of information.

16:09.830 --> 16:15.670
First from the merchant an authorization request is sent to the

16:15.670 --> 16:16.350
payment gateway.

16:16.350 --> 16:21.430
And this is answered sometime later with an authorization response

16:21.430 --> 16:27.050
telling whether the cardholder actually is good for this payment

16:27.050 --> 16:27.650
transaction.

16:28.930 --> 16:31.030
What is the authorization request?

16:31.290 --> 16:34.750
What is the information that the merchant has to compile into this

16:34.750 --> 16:35.230
message?

16:36.350 --> 16:42.190
So certainly there will be some plain text message, this authorization

16:42.190 --> 16:42.630
request.

16:43.630 --> 16:47.970
And certainly this authorization request has to be signed.

16:48.230 --> 16:52.670
So we get this digital signature here for the authorization request.

16:52.670 --> 16:54.010
Both are combined.

16:56.910 --> 17:09.570
And this information here is encrypted using some symmetric key so

17:09.570 --> 17:13.790
that the information that is sent over the communication channel is

17:13.790 --> 17:15.230
not visible to others.

17:15.230 --> 17:19.470
Certainly this authorization request will contain some information

17:19.470 --> 17:25.870
that may be confidential or that has to be protected because it would

17:25.870 --> 17:30.150
be a privacy violation for the merchant if everything would be visible

17:30.150 --> 17:30.550
here.

17:30.690 --> 17:33.550
So this is encrypted using a symmetric key.

17:33.550 --> 17:39.750
This symmetric key certainly has to be encrypted using the payment

17:39.750 --> 17:45.650
gateway's public key exchange key, which the merchant certainly must

17:45.650 --> 17:46.010
know.

17:47.010 --> 17:52.250
So he must have a certificate from the payment gateway, which before

17:52.250 --> 17:54.410
he also has sent already to the cardholder.

17:55.370 --> 18:02.490
And so this encrypted authorization request is one part of the

18:02.490 --> 18:03.050
message.

18:04.050 --> 18:10.710
And certainly this encrypted symmetric key is also included there.

18:11.050 --> 18:14.570
And in order to get access to this authorization request, the bank has

18:14.570 --> 18:19.490
to use this digital envelope, the encrypted symmetric key.

18:20.990 --> 18:26.410
Then the payment information that the cardholder initially compiled

18:26.410 --> 18:30.790
certainly also has to be sent to the payment gateway.

18:30.790 --> 18:36.050
So this was the encrypted payment message from the cardholder and the

18:36.050 --> 18:45.950
payment digital envelope, which was the encrypted symmetric key, which

18:45.950 --> 18:48.170
was used to encrypt the payment message.

18:48.510 --> 18:52.930
And there was this account information, which was also encrypted in

18:52.930 --> 18:53.590
this message.

18:54.380 --> 18:54.830
Okay.

18:55.130 --> 18:57.870
And certainly the necessary certificates are sent.

18:58.330 --> 19:03.550
So the cardholder had sent a certificate to the merchant.

19:03.910 --> 19:09.030
So the cardholder's certificate is forwarded to the bank now or to the

19:09.030 --> 19:10.910
payment gateway.

19:11.650 --> 19:20.350
The merchant has signed the message here in this digital envelope.

19:20.350 --> 19:25.090
So the corresponding certificate for the public key has to be sent.

19:26.170 --> 19:32.750
And this is for verifying the digital signature.

19:33.230 --> 19:38.170
This certificate and the certificate for the key exchange key is

19:38.170 --> 19:42.990
needed for getting access to the encrypted authorization request.

19:43.750 --> 19:47.550
So this is sent to the bank or to the payment gateway.

19:47.550 --> 19:54.530
The payment gateway then processes all this, verifies the encrypted or

19:54.530 --> 20:01.990
first gets access to this authorization request by doing the

20:01.990 --> 20:02.290
following.

20:02.590 --> 20:04.490
The digital envelope has to be opened.

20:04.790 --> 20:08.890
It can be opened using the payment gateway's private key exchange key.

20:09.670 --> 20:15.670
The public key exchange key had been used to get this.

20:17.630 --> 20:22.550
The public key had been used to encrypt the symmetric key.

20:23.150 --> 20:33.390
So the payment gateway uses certainly its own private key in order to

20:33.390 --> 20:35.930
retrieve the symmetric key.

20:35.930 --> 20:42.110
The symmetric key then is used to decrypt the authorization request.

20:42.670 --> 20:46.910
So then we have the authorization request here and the digital

20:46.910 --> 20:55.130
signature, which was also included in this encrypted message.

20:55.530 --> 20:57.990
Both are retrieved from this decryption.

20:57.990 --> 21:05.210
Then the message digest can be computed by the payment gateway, and it

21:05.210 --> 21:12.910
can also be retrieved using the merchant's public signature key.

21:13.110 --> 21:16.890
Where does the payment gateway get this merchant's public signature

21:16.890 --> 21:17.330
key?

21:17.570 --> 21:19.650
It's retrieved from the certificate.

21:20.470 --> 21:24.410
This arrow here is indicating this.

21:24.610 --> 21:28.070
It's coming from the certificate that was at the end of this message.

21:28.570 --> 21:31.070
So this is the standard signature verification.

21:32.210 --> 21:35.330
And down here we have the verification of the information from the

21:35.330 --> 21:35.850
cardholder.

21:36.030 --> 21:44.190
You see it's a sequence of integrity checks, all kinds of

21:44.190 --> 21:46.910
verifications of digital signatures.

21:47.630 --> 21:58.590
So again here, the payment gateway can use its own private key for key

21:58.590 --> 21:59.170
exchanges.

22:00.110 --> 22:03.530
The corresponding public key had been used by the cardholder.

22:04.510 --> 22:13.450
And in this way, the payment gateway can retrieve the symmetric key.

22:13.450 --> 22:17.810
This is one important ingredient and also the account information

22:17.810 --> 22:19.350
about the cardholder.

22:20.090 --> 22:22.910
The symmetric key is used to decrypt the payment information.

22:23.190 --> 22:27.210
And then we have the decrypted payment information and also the dual

22:27.210 --> 22:27.710
signature.

22:28.890 --> 22:35.930
And from the payment information, we can compute the payment

22:35.930 --> 22:38.530
information message digest.

22:38.530 --> 22:47.030
Now, where do we get the order information message digest?

22:47.490 --> 22:49.930
This was included in the authorization request.

22:50.090 --> 22:53.670
Let's look back to that slide.

23:15.110 --> 23:19.670
Here we have the payment information message digest.

23:20.910 --> 23:25.630
Then we have the authorization request.

23:25.630 --> 23:31.030
This must have included the order information message digest as the

23:31.030 --> 23:33.450
merchant had received it.

23:34.410 --> 23:36.570
So this was included there.

23:37.250 --> 23:40.370
It was not explicitly mentioned on the previous slide.

23:41.130 --> 23:46.450
From the combination of both, the payment gateway can compute the

23:46.450 --> 23:48.790
combined digest.

23:48.790 --> 23:54.810
And it could also decrypt the dual signature using the cardholder

23:54.810 --> 23:55.450
certificate.

23:56.750 --> 24:02.270
And so this dual signature is also verified at the payment gateway

24:02.270 --> 24:02.750
site.

24:03.310 --> 24:09.450
So this is a combination of many signatures and all the signatures can

24:09.450 --> 24:10.190
be verified.

24:12.650 --> 24:18.670
Then, after receiving, after decrypting all this information at the

24:18.670 --> 24:22.190
payment gateway site, the payment gateway has to check with the

24:22.190 --> 24:29.690
cardholder's bank whether the balance is okay for this transaction.

24:29.690 --> 24:34.950
So there is an authorization request sent from the payment gateway to

24:34.950 --> 24:38.390
the cardholder's financial institution, credit card company, or

24:38.390 --> 24:38.630
whatever.

24:40.850 --> 24:51.350
And after that, the payment gateway will send an answer to the

24:51.350 --> 24:52.270
merchant.

24:52.270 --> 24:56.930
And now we have another sequence of digital signatures.

24:57.370 --> 25:03.030
The authorization response has to be signed by the payment gateway

25:03.030 --> 25:05.770
using, again, its private signature key.

25:05.950 --> 25:08.910
Here we get the digital signature for the authorization response.

25:12.650 --> 25:16.470
Both parts here are encrypted because this is considered to be

25:16.470 --> 25:17.570
confidential information.

25:17.570 --> 25:21.250
Both are encrypted using a symmetric key, another symmetric key.

25:22.330 --> 25:29.130
So this symmetric key, again, has to be encrypted using the merchant's

25:29.130 --> 25:31.170
public key exchange key.

25:32.050 --> 25:36.410
And so we have here the digital envelope, that means the encrypted

25:36.410 --> 25:39.770
symmetric key and the corresponding encrypted message.

25:41.090 --> 25:44.950
And what else has to be included here?

25:45.850 --> 25:49.510
We have a so-called capture token.

25:50.450 --> 25:51.610
Now, what is a capture token?

25:51.970 --> 26:01.390
The payment gateway has sent this request to the cardholder's

26:01.390 --> 26:05.370
financial institution, bank, or credit card company, and this has

26:05.370 --> 26:08.530
answered, okay, the cardholder is good for this transaction.

26:08.530 --> 26:14.550
That means it has reserved this transaction for later processing.

26:15.190 --> 26:20.170
The amount is not actually deducted from the customer's account

26:20.170 --> 26:22.570
because the transaction is not complete.

26:24.150 --> 26:29.330
So there's no transfer at this moment, but there's only a label on it,

26:29.430 --> 26:30.090
or a token.

26:31.010 --> 26:37.130
This amount will be deducted probably at some later time.

26:37.900 --> 26:39.830
And this is a capture token.

26:39.930 --> 26:44.150
This capture token, or from this label, a capture token is generated,

26:44.670 --> 26:53.110
which later on can be used to actually get the, or to initiate the

26:53.110 --> 26:57.270
fund transfer at the end of this process.

26:58.210 --> 27:04.790
So the capture token is information that will be sent to the merchant,

27:04.790 --> 27:08.130
but the merchant cannot do anything with it.

27:08.230 --> 27:15.130
The merchant can only send it back to the payment gateway and later on

27:15.130 --> 27:18.550
request for transfer of funds.

27:19.770 --> 27:25.370
And so this capture token is encrypted, certainly, because this

27:25.370 --> 27:27.010
certainly is confidential information.

27:27.570 --> 27:31.390
Nobody else should be, or should get access to this capture token

27:31.390 --> 27:36.530
because only the merchant could be capable of actually retrieving this

27:36.530 --> 27:36.850
money.

27:37.430 --> 27:40.230
So it is encrypted using a symmetric key.

27:41.530 --> 27:49.230
And this symmetric key is, again, encrypted using the payment

27:49.230 --> 27:51.950
gateway's public key exchange key.

27:51.950 --> 27:57.530
So the payment gateway itself is encrypting the symmetric key using

27:57.530 --> 28:01.510
its own public key exchange key.

28:01.970 --> 28:10.530
So this envelope can only be opened by the payment gateway itself.

28:10.810 --> 28:13.290
It cannot be opened by the merchant.

28:14.810 --> 28:20.050
Certainly the merchant gets this information because later on it will

28:20.050 --> 28:29.170
have to send this back to the payment gateway in order to actually

28:29.170 --> 28:30.590
initiate the fund transfer.

28:30.590 --> 28:36.090
So this is also a very important part of this payment protocol that we

28:36.090 --> 28:42.750
have this capture token here, which is sent to the merchant in order

28:42.750 --> 28:47.510
to tell the...

28:47.510 --> 28:51.810
certainly not in order to tell the merchant, but as another

28:51.810 --> 28:56.070
information that is necessary for the merchant to be able to later on

28:56.070 --> 28:58.610
retrieve actually the money.

28:58.610 --> 29:07.750
And the contents of this capture token is of no relevance to the

29:07.750 --> 29:11.310
merchant, but only of relevance later on to the payment gateway.

29:11.650 --> 29:16.710
Therefore, the payment gateway is encrypting this symmetric key using

29:16.710 --> 29:20.970
its own public key exchange key.

29:22.090 --> 29:29.090
So this information here, again, is something which is readable only

29:29.090 --> 29:32.010
by the payment gateway, not by the merchant.

29:32.010 --> 29:38.350
Certainly readable, but there's no reasonable information in there.

29:38.530 --> 29:40.590
The merchant cannot retrieve that information.

29:41.930 --> 29:43.430
And what else is in there?

29:43.430 --> 29:48.650
We also need the payment gateway's certificate for its signature key

29:48.650 --> 29:57.030
because the payment gateway had signed its authorization response and

29:57.030 --> 30:00.010
produced this digital signature.

30:00.550 --> 30:06.450
So the merchant must be capable of retrieving that or of checking that

30:06.450 --> 30:07.170
digital signature.

30:08.030 --> 30:12.610
Okay, the merchant retrieves this authorization response.

30:13.290 --> 30:24.030
It will decrypt this authorization message using its own private key

30:24.030 --> 30:30.830
exchange key and then can verify the authorization response in the

30:30.830 --> 30:34.750
normal way by checking the validity of the signature.

30:35.750 --> 30:40.470
Where it got the public key from the payment gateway.

30:41.530 --> 30:47.010
Okay, and certainly the merchant doesn't do anything with this payment

30:47.010 --> 30:49.430
message containing the capture token.

30:52.640 --> 30:53.960
What happens after this?

30:54.800 --> 30:58.020
Certainly the transaction is completed.

30:58.500 --> 31:03.760
The merchant got this hopefully positive statement from the bank.

31:04.580 --> 31:10.420
The product is sent to the customer and the customer is happy.

31:10.880 --> 31:15.320
And now to make the merchant happy, she wants to get the money.

31:15.740 --> 31:19.360
So the payment has to be requested.

31:19.940 --> 31:25.960
So the merchant will send a capture request to the payment gateway and

31:25.960 --> 31:30.140
the payment gateway will process this capture request and send an

31:30.140 --> 31:32.340
appropriate capture response to the merchant.

31:32.340 --> 31:36.420
This now looks as this here.

31:37.080 --> 31:42.780
The merchant has to put some information in this capture request.

31:43.780 --> 31:54.240
All this information that had to be sent in these different steps of

31:54.240 --> 32:01.500
this protocol, this information certainly is specified to quite some

32:01.500 --> 32:03.440
detail in the SCT protocol.

32:03.440 --> 32:08.340
But as I said before, I don't want to go into the details of the

32:08.340 --> 32:14.620
format for these requests and answers and so on, because here I want

32:14.620 --> 32:18.660
to look mainly at the cryptographic parts of this.

32:18.660 --> 32:24.960
So the capture request by the merchant is certainly signed by the

32:24.960 --> 32:25.320
merchant.

32:25.700 --> 32:30.520
Signature and capture requests are encrypted because this certainly is

32:30.520 --> 32:31.640
confidential information.

32:32.320 --> 32:36.840
Using another symmetric key, the symmetric key again is encrypted

32:36.840 --> 32:39.860
using the payment gateway's public key exchange key.

32:41.500 --> 32:46.020
This then is the capture request message encrypted with this envelope.

32:46.880 --> 32:52.540
And the other part is the payment information or this capture token

32:52.540 --> 32:56.580
that the payment gateway had sent previously.

32:57.460 --> 33:00.880
And then what else does the recipient need?

33:00.980 --> 33:05.220
The payment gateway needs the merchant's certificate for its signature

33:05.220 --> 33:07.420
key and for its key exchange key.

33:09.200 --> 33:17.280
And then the payment gateway receives the payment capture or this

33:17.280 --> 33:18.880
information from the merchant.

33:19.480 --> 33:21.960
Now what does the payment gateway do?

33:21.960 --> 33:27.260
The payment gateway can now use its own private key exchange key in

33:27.260 --> 33:31.480
order to decrypt this symmetric key.

33:32.100 --> 33:37.260
Open the envelope, then it can decrypt this capture.

33:38.680 --> 33:44.100
No, sorry, this was the encrypted capture request message.

33:44.220 --> 33:45.580
The capture token is down here.

33:45.940 --> 33:48.240
This was the part that the merchant compiled.

33:49.080 --> 33:51.160
So this was compiled by the merchant.

33:56.810 --> 33:58.710
There should be a C down there.

34:00.450 --> 34:02.090
This was the merchant's part.

34:02.950 --> 34:10.210
So the envelope was encrypted with the payment gateway's public key

34:10.210 --> 34:12.090
for the key exchange key.

34:13.190 --> 34:18.290
And it certainly can be verified checking the digital signature.

34:18.290 --> 34:22.310
The corresponding public key is coming from the merchant's

34:22.310 --> 34:22.750
certificate.

34:23.750 --> 34:29.490
And this here was compiled previously by the payment gateway.

34:36.820 --> 34:41.980
And now the payment gateway can retrieve this information again using

34:41.980 --> 34:48.740
its own private key for the key exchange key pair.

34:49.080 --> 34:51.580
It can decrypt the capture token.

34:52.360 --> 34:58.800
And then the payment gateway has again this capture token which it had

34:58.800 --> 35:01.220
sent to the merchant previously.

35:01.880 --> 35:06.400
And now this capture token can be used to actually initiate the

35:06.400 --> 35:08.340
transfer of funds.

35:10.320 --> 35:15.500
So the capture request and capture token is sent using another

35:15.500 --> 35:19.840
protocol from the payment gateway to the cardholder's financial

35:19.840 --> 35:20.500
institution.

35:20.500 --> 35:32.420
And then after this is complete, the payment gateway actually sends

35:32.420 --> 35:34.740
another information.

35:36.520 --> 35:44.000
No, this is the

35:49.310 --> 35:55.590
capture response at the payment gateway.

35:55.590 --> 36:07.270
So this is the payment capture response message.

36:07.330 --> 36:12.690
That means this is the message that the payment gateway here, the

36:12.690 --> 36:17.730
payment gateway had sent the capture request and capture token to the

36:17.730 --> 36:19.310
cardholder's financial institution.

36:20.210 --> 36:24.010
The transfer of funds has been initiated.

36:25.110 --> 36:30.970
And then the payment gateway has sent in the corresponding response

36:30.970 --> 36:32.190
message for the merchant.

36:32.710 --> 36:38.310
And this is at the merchant's site, the processing of the response

36:38.310 --> 36:38.950
message.

36:38.950 --> 36:47.650
So the merchant has to again decrypt the response message from the

36:47.650 --> 36:48.410
payment gateway.

36:49.450 --> 36:54.850
And it uses certainly its private key exchange key.

36:55.610 --> 36:58.950
And again has to verify the digital signature.

36:59.930 --> 37:02.910
And this then should be the end of this protocol.

37:03.690 --> 37:08.990
Because then, like here, this was the final statement from the payment

37:08.990 --> 37:12.290
gateway that everything has been transferred correctly.

37:12.870 --> 37:15.610
So what are the major ingredients again?

37:17.070 --> 37:23.990
We have the dual signature, which separates the information that the

37:23.990 --> 37:27.130
customer or the cardholder sends to the merchant.

37:27.130 --> 37:30.290
Just the order information is sent to the merchant.

37:30.530 --> 37:34.070
The payment information is only sent in encrypted form such that only

37:34.070 --> 37:36.970
the bank can access that information.

37:37.770 --> 37:46.070
And we have these two separate public key pairs for exchanging session

37:46.070 --> 37:47.510
keys and for digital signatures.

37:48.430 --> 37:55.630
And finally, we have the use of capture tokens to allow for secure

37:55.630 --> 38:02.410
claiming of funds after the purchase actually has taken place.

38:03.170 --> 38:06.510
So this is very important.

38:06.690 --> 38:10.970
The merchant has no chance to modify the capture token without being

38:10.970 --> 38:11.430
noticed.

38:11.430 --> 38:13.890
The merchant has no access to this capture token.

38:14.430 --> 38:18.330
She cannot modify the amount that has to be paid.

38:19.270 --> 38:24.690
But this is only readable by the payment gateway.

38:25.390 --> 38:33.230
Okay, so this protocol, as you have seen, is an application of this

38:33.230 --> 38:37.190
standard communication protocol, which I presented to you at the end

38:37.190 --> 38:38.190
of the previous chapter.

38:39.450 --> 38:46.050
And as you see, quite a few places where digital signatures have to be

38:46.050 --> 38:46.570
verified.

38:47.030 --> 38:52.950
And again, this important idea of the dual signature.

38:53.530 --> 38:57.470
So we have a high degree of anonymity in this protocol, much higher

38:57.470 --> 39:03.710
than we have in the paper-based credit card payment protocol.

39:03.710 --> 39:09.930
There you hand out your signature, your real signature, credit card

39:09.930 --> 39:14.090
number, and your name to the merchant.

39:14.470 --> 39:18.870
So you provide much more information than in this protocol.

39:18.870 --> 39:26.050
Certainly, in order to get into widespread use, this SCT protocol,

39:26.890 --> 39:32.210
well, should be, the best would be available for free.

39:32.530 --> 39:37.890
But if this is a commercial product, it's certain that this is

39:37.890 --> 39:38.350
expensive.

39:39.170 --> 39:43.670
And so this is one of the major reasons why SCT is not in very

39:43.670 --> 39:44.890
widespread use.

39:46.070 --> 39:57.390
It is expensive to get installed at the merchant's side, the

39:57.390 --> 39:59.370
cardholder's side, and so on.

39:59.930 --> 40:06.770
So the transaction costs are not neglectable.

40:07.770 --> 40:10.130
And therefore, this is a problem for this protocol.

40:10.130 --> 40:11.550
It is a very nice protocol.

40:11.790 --> 40:16.030
It really is a payment protocol because it's going into the

40:16.030 --> 40:16.610
application.

40:18.150 --> 40:23.610
But this is certainly leading to overhead costs.

40:23.990 --> 40:31.710
And as you see, very often people request for anonymity and protection

40:31.710 --> 40:32.490
of the privacy.

40:32.490 --> 40:36.310
But as soon as they have to pay for it, they forget about these

40:36.310 --> 40:36.830
requests.

40:37.680 --> 40:43.530
And we have to see how this will develop in the future.

40:44.510 --> 40:49.750
Okay, I want to present to you now a different payment protocol,

40:50.170 --> 41:00.070
CyberCash, which is slightly different from the SCT protocol, not as

41:00.070 --> 41:01.230
anonymous.

41:04.870 --> 41:09.930
So this is essentially, at the first sight, it looks very similar to

41:09.930 --> 41:11.530
what we have seen before.

41:11.650 --> 41:17.310
We have the customer, we have the merchant, and the merchant is

41:17.310 --> 41:20.630
communicating with the bank payment server.

41:20.630 --> 41:26.910
The payment server or payment gateway, again, is communicating with

41:26.910 --> 41:31.750
the merchant's bank or some third-party processor.

41:32.170 --> 41:38.010
And then the cardholder's bank, this bank is finally communicating

41:38.010 --> 41:40.750
with the cardholder's bank, performing the transactions that are

41:40.750 --> 41:41.230
necessary.

41:42.070 --> 41:46.830
And so, again, we have processing of payment information, but in a

41:46.830 --> 41:48.250
slightly different way.

41:48.250 --> 41:53.870
Now I want to briefly present to you an animation that you can

41:53.870 --> 41:58.290
retrieve at this CyberCash.com URL.

41:59.290 --> 42:08.890
I just use it here from my... I have it locally here on my PC.

42:09.930 --> 42:17.250
So we should just look at this here.

42:22.180 --> 42:30.780
So this is from this CyberCash website, and I just want to briefly

42:30.780 --> 42:34.380
present to you this information.

42:35.380 --> 42:43.140
I hope that... I think there's also some... hope that this works

42:43.140 --> 42:44.100
now...

42:44.100 --> 42:50.080
also some sound associated with this.

42:50.940 --> 42:52.760
So, let's see.

42:53.620 --> 42:54.420
No sound.

42:58.160 --> 43:04.980
So, a consumer is shopping for flowers on the Internet using its

43:04.980 --> 43:05.500
computer.

43:07.100 --> 43:09.520
Then what does the consumer do?

43:09.640 --> 43:12.820
The consumer enters shipping and credit card information to secure a

43:12.820 --> 43:13.060
form.

43:15.180 --> 43:18.840
Remember, we had the separation of order information and payment

43:18.840 --> 43:20.480
information in the ICT protocol.

43:20.480 --> 43:25.320
Here, we provide shipping and credit card information into a secure

43:25.320 --> 43:25.840
form.

43:26.420 --> 43:29.720
Here, SSL is used as the encryption method.

43:30.760 --> 43:37.540
But, as you know, this is just on the logical connection between the

43:37.540 --> 43:38.440
two hosts.

43:40.320 --> 43:44.300
So, here we have this information.

43:44.300 --> 43:49.760
Then the consumer is presented with a summary of items, price, and

43:49.760 --> 43:50.500
billing info.

43:53.280 --> 44:01.580
The consumer has to take all this, or the consumer has to check this

44:01.580 --> 44:02.140
was okay.

44:02.500 --> 44:04.800
Then the information is sent to the shop.

44:05.540 --> 44:11.900
There, the payment information is sent using secure HTTP.

44:12.280 --> 44:18.760
So, it's a combination of HTTP with SSL to the merchant's SSL-enabled

44:18.760 --> 44:19.400
web server.

44:19.800 --> 44:23.560
So, this is not secure on the application level, but only at the TCP

44:23.560 --> 44:24.080
level.

44:24.580 --> 44:28.080
The order is passed on to the storefront software.

44:29.070 --> 44:37.680
And there, the merchant's storefront software passes this payment

44:37.680 --> 44:41.960
information to the merchant connection kit, some special part of the

44:41.960 --> 44:48.500
software, which encrypts the transaction with triple-DES industrial

44:48.500 --> 44:49.580
-strength encryption.

44:50.100 --> 44:52.820
So, this should be sufficient.

44:53.820 --> 44:58.980
So, then, this is actually encryption on the application level.

45:00.620 --> 45:06.200
Next step is to send this information over the Internet through the

45:06.200 --> 45:13.320
firewall, which you see here, to the CyberCache payment server.

45:13.920 --> 45:18.040
So, it's sent to the CyberCache servers.

45:18.040 --> 45:25.880
There, it is processed and sent to the merchant's financial

45:25.880 --> 45:26.540
institution.

45:27.860 --> 45:33.580
Then, the merchant's financial institution has to communicate with the

45:33.580 --> 45:39.720
consumer's credit card bank to check for validity of this request.

45:39.980 --> 45:44.600
So, this is this request, which will be answered in some way.

45:44.600 --> 45:49.460
For example, in this way, telling everything is okay.

45:50.860 --> 45:53.520
You can process this transaction.

45:55.220 --> 45:59.620
And then, this is sent back to the CyberCache.

45:59.740 --> 46:05.280
CyberCache is sending the information back to the flower shop.

46:08.020 --> 46:14.780
And then, the flower shop sends this information on to the customer.

46:15.900 --> 46:20.600
And the next step is that the flowers actually get to the customer.

46:22.320 --> 46:27.540
And after that, the merchant requests financial settlement or capture.

46:27.540 --> 46:31.380
Remember, we had the same step in the SET protocol.

46:32.060 --> 46:38.540
A capture request is sent to the bank after the product has been

46:38.540 --> 46:40.520
shipped to the customer.

46:40.520 --> 46:43.780
Here, the balance is shown.

46:45.140 --> 46:53.340
And then, we have actually an additional amount of $30, which is added

46:53.340 --> 46:57.700
to the account of the merchant.

46:58.800 --> 47:05.820
So, actually, certainly, this payment transaction time is much shorter

47:05.820 --> 47:09.580
than what we just saw just now.

47:09.580 --> 47:11.340
So, it's under five seconds.

47:11.520 --> 47:15.800
It should be, well, something at most that much.

47:16.440 --> 47:19.080
Certainly, the delivery of the flowers can take a little longer,

47:19.240 --> 47:19.500
maybe.

47:20.360 --> 47:25.740
So, you see, there are essentially the same steps involved here, or

47:25.740 --> 47:26.480
similar steps.

47:26.960 --> 47:33.760
But the confidentiality requirements here are not as strong as in the

47:33.760 --> 47:34.560
SET protocol.

47:35.490 --> 47:41.340
We have only SSL encryption on the connection between the cardholder

47:41.340 --> 47:45.300
or the customer and the merchant.

47:46.240 --> 47:52.220
And only the information from the merchant to the bank actually is

47:52.220 --> 47:54.920
encrypted on the application layer.

47:56.940 --> 47:57.780
Okay.

47:58.480 --> 48:04.360
So, that was this brief animation of the CyberCash protocol.

48:05.080 --> 48:12.640
So, let's go now back to our presentation here of the protocol.

48:12.800 --> 48:15.980
This was a brief explanation of what happens there.

48:17.900 --> 48:23.120
It's, as I said, in some ways similar to CyberCash, certainly because

48:23.120 --> 48:24.940
there are the same partners.

48:25.520 --> 48:30.080
Similar transactions take place, but the confidentiality requirements

48:30.080 --> 48:30.800
are different.

48:31.540 --> 48:38.040
The merchant server gets more information about the customer than in

48:38.040 --> 48:40.480
the SET protocol.

48:41.180 --> 48:45.840
In the SET protocol, we had the encrypted payment information.

48:46.060 --> 48:49.200
Here, the payment information is not encrypted.

48:51.560 --> 49:01.680
And now we want to look at another way of processing or of realizing

49:01.680 --> 49:05.300
payment over the Internet.

49:06.040 --> 49:07.880
And this is eCash.

49:07.880 --> 49:15.100
eCash is something which can be called real electronic money.

49:15.320 --> 49:20.920
What we have looked at so far is just the processing of credit card

49:20.920 --> 49:21.500
information.

49:22.280 --> 49:27.540
Now we want to get at something which is equivalent to what we have in

49:27.540 --> 49:28.120
our wallet.

49:28.560 --> 49:31.220
In our wallet, we have some coins.

49:32.120 --> 49:36.160
And here we want to have some coins in our computer.

49:36.160 --> 49:46.760
So it should be the electronic correspondence of the coins in our

49:46.760 --> 49:47.160
wallet.

49:47.980 --> 49:54.020
So what can be an electronic copy of a coin?

49:54.960 --> 49:58.120
The coin will be some piece of information on the computer.

49:58.760 --> 50:01.500
The coin will just be some file.

50:01.500 --> 50:07.500
And this is already one of the major problems of this system.

50:08.400 --> 50:12.160
If you have some file on your computer, you certainly can copy that

50:12.160 --> 50:12.540
file.

50:13.600 --> 50:15.300
So this is perfect.

50:16.020 --> 50:20.020
If we could do that with our coins in our pockets, if you have one

50:20.020 --> 50:22.660
coin, you can just produce as many copies as you like.

50:23.380 --> 50:24.800
That would be perfect.

50:24.800 --> 50:31.000
But certainly, if you produce copies of your coins, this usually will

50:31.000 --> 50:35.820
be noticed by the banks.

50:36.300 --> 50:40.760
And you get punished for that as soon as it is noticed.

50:40.760 --> 50:53.140
So if coins exist as a file, the persons who take a file as being

50:53.140 --> 50:59.760
equivalent to some piece of money, to some coin, then they must have a

50:59.760 --> 51:03.340
way of checking whether this actually is a valid copy.

51:04.200 --> 51:08.900
And this is one of the major points that has to be looked at.

51:10.380 --> 51:15.140
eCash is something which is independent of other existing systems of

51:15.140 --> 51:16.160
credit cards, etc.

51:16.420 --> 51:20.820
It's a completely independent system, and it's a completely anonymous

51:20.820 --> 51:21.400
system.

51:22.700 --> 51:30.080
In the same way as cash is anonymous, if you get cash from somebody

51:30.080 --> 51:34.000
else, you don't know where this person got this cash from before.

51:36.720 --> 51:40.780
And the drawback is that it is an online solution.

51:41.020 --> 51:47.380
That means the merchant has to be online in order to be able to

51:47.380 --> 51:53.700
actually check the validity of the coins that she gets from the

51:53.700 --> 51:54.140
customer.

51:55.120 --> 51:59.480
And, well, representation of the value is by electronic coins, as we

51:59.480 --> 52:00.220
will see in a moment.

52:00.220 --> 52:07.480
The things that are used are RSA, public key encryption, and blind

52:07.480 --> 52:08.500
digital signatures.

52:08.760 --> 52:13.660
So we have seen digital signatures, dual signatures, now we get third

52:13.660 --> 52:17.340
variant blind digital signatures.

52:18.820 --> 52:24.360
And we will look at more details of this system.

52:24.360 --> 52:29.500
In eCash, certainly we also have three partners, three parties that

52:29.500 --> 52:30.840
have to communicate.

52:31.480 --> 52:34.200
The bank, the customers, and the merchants.

52:35.280 --> 52:39.880
The customers will have an account at some bank.

52:40.700 --> 52:45.560
So there must be some relationship of the customer with some bank.

52:46.520 --> 52:52.200
And they want to withdraw eCash from the bank.

52:54.380 --> 53:02.320
So the banks, only the banks can issue coins, can validate coins.

53:03.900 --> 53:08.200
You don't have this donkey that produces gold.

53:08.720 --> 53:10.860
So the bank can only do that.

53:11.860 --> 53:18.180
And certainly the bank can also change real money into eCash.

53:18.360 --> 53:23.380
So the customer says, I want to deduct a certain amount of money from

53:23.380 --> 53:24.420
my account.

53:25.080 --> 53:31.760
And I want to get electronic coins for the same amount.

53:32.220 --> 53:35.940
And the bank should send this amount in eCash to the customer.

53:35.940 --> 53:42.460
Now the customer will go shopping with its eCash to merchants which

53:42.460 --> 53:43.740
accept eCash.

53:44.760 --> 53:50.440
So the merchant gets these files claiming to be valid coins.

53:51.480 --> 53:55.680
And in order to check that, the merchant will actually go back to the

53:55.680 --> 54:01.160
bank and ask it, is this file actually a valid eCash coin?

54:02.100 --> 54:06.720
And the bank will check, in a way we will look at in a moment.

54:07.400 --> 54:09.640
And will say, okay, this is valid.

54:10.400 --> 54:16.260
And then the merchant will actually hand out the product to the

54:16.260 --> 54:16.640
customer.

54:17.440 --> 54:23.540
So again, we have this combination of transactions between customers,

54:23.760 --> 54:24.840
merchants, and banks.

54:24.840 --> 54:28.340
But in a way that now is completely anonymous.

54:29.280 --> 54:37.620
The bank here will not know who actually bought anything or is

54:37.620 --> 54:39.620
involved here on the customer side.

54:39.940 --> 54:45.740
Like who this customer actually is, is not known to the bank.

54:46.740 --> 54:54.060
The bank certainly will know that at some time it sent certain coins

54:54.060 --> 54:54.880
to the customer.

54:55.640 --> 55:03.500
But this must be done in a way such that the bank later on cannot find

55:03.500 --> 55:09.040
out from the coins that it gets from the merchant who actually this

55:09.040 --> 55:10.280
customer was.

55:10.280 --> 55:19.660
That means the bank must not store the serial numbers of the coins

55:19.660 --> 55:21.980
that it sends to the customer.

55:23.040 --> 55:28.940
But nevertheless, it must be capable of checking whether a coin with a

55:28.940 --> 55:33.160
certain serial number on it that it receives from a merchant is a

55:33.160 --> 55:33.900
valid coin.

55:35.200 --> 55:40.920
And so this is the major point how one can actually achieve this

55:40.920 --> 55:46.940
anonymity that the bank can issue electronic coins, send them to the

55:46.940 --> 55:55.340
customer without storing any record about these coins that it

55:55.340 --> 56:03.020
validated such that the customer can go shopping without penetration

56:03.020 --> 56:04.920
into the customer's privacy.

56:05.840 --> 56:07.760
Okay, we will look at this.

56:08.220 --> 56:11.600
So how can we actually generate electronic coins?

56:11.600 --> 56:19.800
The customer has certain software on her computer and it's in the

56:19.800 --> 56:20.540
cyber wallet.

56:21.380 --> 56:27.180
And this cyber wallet generates random serial numbers.

56:28.340 --> 56:33.440
So if you want to get money, you generate your own serial numbers for

56:33.440 --> 56:34.940
the coins you want to use.

56:35.880 --> 56:42.580
Certainly, in order to guarantee uniqueness of these coins, the

56:42.580 --> 56:52.160
customer has to generate sufficiently long serial numbers.

56:52.160 --> 57:01.760
Now, for every serial number, the desired coin value is fixed.

57:01.760 --> 57:10.280
So you want to issue 5 EUR or 10 EUR or maybe 100 EUR or 1 cent coin.

57:12.040 --> 57:23.080
And so this is the serial number and the desired coin value.

57:23.360 --> 57:30.920
And then the hidden serial numbers and coin values are sent to the

57:30.920 --> 57:31.340
bank.

57:32.340 --> 57:40.400
Hidden serial numbers and coin values encrypted with the customer's

57:40.400 --> 57:41.960
private key.

57:42.980 --> 57:50.000
So you have this coin with some number on it.

57:51.260 --> 57:54.580
Then you hide this in some way.

57:54.860 --> 57:59.820
You put this into some envelope.

58:01.260 --> 58:05.200
Hide this somewhere or somehow put it in an envelope.

58:06.260 --> 58:07.680
The number is hidden.

58:07.940 --> 58:08.980
It's sent to the bank.

58:09.980 --> 58:18.600
And the bank will have to validate the coins using a blind signature.

58:18.600 --> 58:22.620
Now, you know this from real world, from paper.

58:23.340 --> 58:29.360
There are sometimes envelopes that you can sign, but you don't see

58:29.360 --> 58:30.800
what's inside of this envelope.

58:31.360 --> 58:33.480
There's black carbon paper in there.

58:33.980 --> 58:38.720
And on the piece of paper that is in there, you have a signature.

58:39.720 --> 58:48.340
But if I write something on this here, then this will only be on the

58:48.340 --> 58:53.020
envelope, but also inside the envelope on the piece of paper that is

58:53.020 --> 58:55.120
in this envelope.

58:56.580 --> 59:04.980
And so this idea is also realized in the blind signature in an

59:04.980 --> 59:05.800
electronic way.

59:06.960 --> 59:14.820
So the issuing bank will sign this random number, the serial number.

59:15.600 --> 59:19.860
It will deduct the corresponding amount from the customer's account.

59:20.000 --> 59:22.040
So this was a coin, let's say, for 5 euro.

59:22.760 --> 59:25.760
The bank will deduct 5 euro from the customer's account.

59:26.400 --> 59:29.580
And it will send the validated coins back to the customer.

59:30.860 --> 59:36.700
Using the customer's public key, such that this is confidential

59:36.700 --> 59:38.600
information.

59:39.280 --> 59:41.680
Since this is confidential information.

59:43.340 --> 59:50.360
And the customer software then will make the serial numbers visible

59:50.360 --> 59:50.860
again.

59:51.600 --> 59:58.980
So it will take this piece of paper out of this envelope.

01:00:00.000 --> 01:00:02.480
And now the signature is on it.

01:00:03.740 --> 01:00:11.200
And in this way we have a validated coin.

01:00:12.020 --> 01:00:13.660
Now, how is this done?

01:00:14.280 --> 01:00:15.960
What is this blind signature about?

01:00:15.960 --> 01:00:24.820
The problem is, Alice wants to have Bob sign a message, M, without Bob

01:00:24.820 --> 01:00:26.400
knowing this message.

01:00:27.740 --> 01:00:32.880
What I said, she puts it in an envelope, Bob has to sign on it.

01:00:33.340 --> 01:00:35.300
So hide M in a blinding envelope.

01:00:36.940 --> 01:00:41.620
And have Bob sign this envelope, take the signed message from the

01:00:41.620 --> 01:00:41.940
envelope.

01:00:41.940 --> 01:00:46.800
So then Bob has signed this message without knowing what's in there.

01:00:47.900 --> 01:00:53.720
How can we do this using an algorithm?

01:00:54.320 --> 01:00:55.900
What we do is the following.

01:00:56.840 --> 01:01:01.560
We have here Bob's public and private keys.

01:01:03.040 --> 01:01:09.680
Actually this should be, I usually said not P and S, this should be C

01:01:09.680 --> 01:01:11.000
and D.

01:01:12.640 --> 01:01:19.700
This was a typing error, C and D is in there, so this is C and D, not

01:01:19.700 --> 01:01:20.880
P and S.

01:01:21.860 --> 01:01:25.680
So, these are Bob's public and private keys.

01:01:27.260 --> 01:01:40.960
And Alice now chooses a random number R, such that R is prime with

01:01:40.960 --> 01:01:42.800
respect to N.

01:01:43.140 --> 01:01:49.000
N is known to Alice, so she chooses such a random number.

01:01:49.760 --> 01:01:55.900
And then she sends Bob the hidden message.

01:01:56.000 --> 01:01:58.540
Now, how can she hide the message M?

01:01:58.720 --> 01:02:05.580
She just multiplies the message M with R to the C.

01:02:07.360 --> 01:02:12.040
Now, R to the C, R is this random number that Alice chooses.

01:02:13.000 --> 01:02:16.820
She knows the value of C, she knows N.

01:02:16.820 --> 01:02:22.360
So, she just computes R to the C times M modulo N.

01:02:22.720 --> 01:02:24.840
This is the new message M prime.

01:02:24.980 --> 01:02:30.700
So, this message M prime is now the message M in this blinding

01:02:30.700 --> 01:02:31.460
envelope.

01:02:33.320 --> 01:02:38.520
Alice sends Bob this hidden message, certainly in some secure way.

01:02:39.440 --> 01:02:44.040
She may use any additional cryptographic protocol for that, but this

01:02:44.040 --> 01:02:45.580
is not of any relevance in the moment.

01:02:45.580 --> 01:02:51.960
Bob will return his signature of this message M prime.

01:02:52.120 --> 01:02:54.420
What is Bob's signature of this message?

01:02:54.600 --> 01:03:06.160
Here it is meant that Bob uses his private key for encrypting this

01:03:06.160 --> 01:03:06.580
message.

01:03:06.920 --> 01:03:11.440
So, M prime is taken to the power D modulo N.

01:03:12.200 --> 01:03:15.900
He uses his private key in order to sign M prime.

01:03:17.940 --> 01:03:19.760
Now, this is U prime.

01:03:20.120 --> 01:03:21.280
But what was M prime?

01:03:21.580 --> 01:03:26.200
M prime was R to the C times M.

01:03:28.260 --> 01:03:30.340
Now, this is taken to the power D.

01:03:32.560 --> 01:03:40.020
Now, if we look at that, this certainly is R to the C times D times M

01:03:40.020 --> 01:03:42.440
to the D modulo N, which you see here.

01:03:42.780 --> 01:03:49.180
So, this is what U prime actually is here.

01:03:49.180 --> 01:03:58.120
So, the result of the encryption of M prime using Bob's private key is

01:03:58.120 --> 01:04:04.540
a number which is R times M to the D modulo N.

01:04:05.280 --> 01:04:10.060
R was this random number that Alice had chosen.

01:04:11.600 --> 01:04:23.980
Now, since R is prime with respect to N, we can cancel out R again, or

01:04:23.980 --> 01:04:28.120
Alice can do that, because Alice knows the value of R.

01:04:29.120 --> 01:04:37.960
So, she can invert R and compute now U prime times R to the minus 1,

01:04:38.560 --> 01:04:43.900
taking the multiplicative inverse of R modulo N, which exists since it

01:04:43.900 --> 01:04:46.000
is prime with respect to N.

01:04:46.800 --> 01:04:53.200
And if we compute U prime with the multiplicative inverse of R modulo

01:04:53.200 --> 01:05:00.660
N, then Alice retrieves U, which is just M to the D mod N.

01:05:01.180 --> 01:05:03.020
Now, what is M to the D mod N?

01:05:03.440 --> 01:05:10.600
This is M encrypted using Bob's private key.

01:05:11.560 --> 01:05:20.620
D is Bob's private key, and that means M, this secret message, has

01:05:20.620 --> 01:05:22.300
been signed by Bob.

01:05:23.760 --> 01:05:33.020
And the blinding factor R had been inserted by Alice using this random

01:05:33.020 --> 01:05:38.380
number R, and Alice is the only person who knows this blinding factor

01:05:38.380 --> 01:05:44.140
R, and so only she can cancel out this blinding factor R again and

01:05:44.140 --> 01:05:47.860
retrieve this serial number.

01:05:48.860 --> 01:05:55.500
Now, Alice knows the message M, she also has the encrypted version,

01:05:58.080 --> 01:06:12.120
and what she also knows is the public key of Bob.

01:06:13.360 --> 01:06:25.200
And so, later on, if Bob would get this message here, M to the D, Bob

01:06:25.200 --> 01:06:34.920
could verify whether this actually has been signed by using his own

01:06:34.920 --> 01:06:37.480
private key.

01:06:38.360 --> 01:06:46.080
So, certainly in real life, there will be more than just this serial

01:06:46.080 --> 01:06:50.960
number that has to be signed to get a coin, so that later on the bank

01:06:50.960 --> 01:06:58.160
can verify that a correct serial number had been used.

01:06:58.160 --> 01:07:04.040
So, let's look how we use this blind signature again in the bank

01:07:04.040 --> 01:07:04.700
transaction.

01:07:05.240 --> 01:07:08.500
Here's just this one more statement, only Bob could generate the

01:07:08.500 --> 01:07:13.200
signature U of M, although he did not sign M but M'.

01:07:13.840 --> 01:07:20.840
And any other person can verify that Bob has signed M, because there

01:07:20.840 --> 01:07:26.980
is this signature here.

01:07:26.980 --> 01:07:33.720
So, if you get the random number and this encrypted information, you

01:07:33.720 --> 01:07:42.400
can verify that the serial number is correct by just decrypting this

01:07:42.400 --> 01:07:44.180
message here.

01:07:45.180 --> 01:07:45.700
Okay.

01:07:47.760 --> 01:07:52.060
So, again, what happens?

01:07:52.480 --> 01:07:57.080
The customer blinds serial numbers of the coin.

01:07:57.840 --> 01:08:03.120
So, this is what just before Alice's part was.

01:08:03.700 --> 01:08:10.380
The customer now blinds the serial numbers of the coins and puts the

01:08:10.380 --> 01:08:12.140
coins into a digital envelope.

01:08:12.920 --> 01:08:16.500
He certainly signs this envelope with his private key.

01:08:16.940 --> 01:08:22.560
This is additional safety, which is added.

01:08:24.920 --> 01:08:29.760
So, the bank certainly knows then that the customer actually has sent

01:08:29.760 --> 01:08:30.640
this information.

01:08:31.360 --> 01:08:35.040
The customer sends the coins to the bank, as you can see here.

01:08:37.140 --> 01:08:44.920
This sealed envelope is sent to the bank, encrypted with the bank's

01:08:44.920 --> 01:08:50.900
public key, such that nobody else can access that information.

01:08:52.140 --> 01:08:55.740
The bank then verifies the customer's signature.

01:08:57.540 --> 01:09:01.540
This was like the customer had signed with his private key.

01:09:01.680 --> 01:09:07.200
So, the bank verifies the customer's signature, signs the coins with

01:09:07.200 --> 01:09:12.140
its private key, corresponding to the requested amount.

01:09:12.140 --> 01:09:19.860
So, you have to assume that the bank can use different public-private

01:09:19.860 --> 01:09:26.040
key pairs for every amount that is requested by the customers.

01:09:26.860 --> 01:09:32.240
So, the bank has its 5 euro key pair, its 1 cent key pair, and so on.

01:09:34.220 --> 01:09:42.860
And so, this serial number is signed by these coins, or serial numbers

01:09:42.860 --> 01:09:48.120
are signed by the bank using the corresponding private keys.

01:09:48.800 --> 01:09:54.200
And the appropriate amount is deducted from the customer's account.

01:09:56.260 --> 01:10:02.460
As I said already, the bank has a different key pair for every coin

01:10:02.460 --> 01:10:02.980
value.

01:10:03.740 --> 01:10:08.080
And this certainly is specified in the keys certificate, which

01:10:08.080 --> 01:10:11.880
certainly is also sent back later on to the customer.

01:10:11.880 --> 01:10:17.420
So, the bank returns the validated blinded coins to the customer,

01:10:18.060 --> 01:10:24.140
encrypted with the customer's public key, such that only the customer

01:10:24.140 --> 01:10:26.800
can actually retrieve these coins.

01:10:27.680 --> 01:10:32.120
And, in addition to the blinded coins, certainly the bank sends its

01:10:32.120 --> 01:10:38.500
certificates about its public keys for the specific coin values.

01:10:39.740 --> 01:10:46.940
And then, the customer uses his or her private key to decrypt the

01:10:46.940 --> 01:10:53.680
bank's message, this was encrypted with his public key, and removes

01:10:53.680 --> 01:10:54.780
the blinding factor.

01:10:56.520 --> 01:11:02.820
And then, the customer has the electronic coins, which consist of this

01:11:02.820 --> 01:11:08.360
serial number, this random serial number generated by the customer,

01:11:09.160 --> 01:11:14.940
this blind signature, and the certificate.

01:11:16.320 --> 01:11:20.500
These are the three ingredients that are necessary, the serial number,

01:11:20.620 --> 01:11:22.880
the signature, and the bank's certificate.

01:11:24.900 --> 01:11:31.640
So, everybody can use the certificate in order to check whether

01:11:31.640 --> 01:11:38.080
actually the signature corresponds to the serial number, so we have a

01:11:38.080 --> 01:11:38.940
check of integrity.

01:11:39.590 --> 01:11:44.020
So, this everybody can do, the only problem is, if you accept

01:11:44.020 --> 01:11:49.540
electronic coins, you certainly can check whether signature and serial

01:11:49.540 --> 01:11:56.280
number coincide, but what you cannot check is whether you are the

01:11:56.280 --> 01:12:03.380
first person who gets this coin, or whether this coin has been used

01:12:03.380 --> 01:12:06.220
already, or has been copied.

01:12:06.220 --> 01:12:09.740
Certainly, you can make as many copies of this information as you

01:12:09.740 --> 01:12:10.040
like.

01:12:12.520 --> 01:12:22.060
Now, if you go shopping with eCash, you have to go to the merchant

01:12:22.060 --> 01:12:31.120
that actually can process eCash, so there will be a payment request as

01:12:31.120 --> 01:12:34.240
soon as you want to get some product, you get a payment request from

01:12:34.240 --> 01:12:40.520
the merchant, the customer sends the coins, the merchant has to access

01:12:40.520 --> 01:12:56.120
online the eCash bank, and the eCash bank sends a verification of the

01:12:56.120 --> 01:12:56.420
coins.

01:12:56.420 --> 01:13:00.460
Now, how can the bank verify that this is a valid coin?

01:13:00.580 --> 01:13:07.980
Certainly, the bank can check whether the bank now has signed this

01:13:07.980 --> 01:13:10.760
coin, whether it is a valid serial number.

01:13:11.480 --> 01:13:16.840
But since the bank had no chance of storing in any way serial numbers

01:13:16.840 --> 01:13:21.140
that it signed, it didn't get to know the serial numbers, only at this

01:13:21.140 --> 01:13:28.820
moment, when there is this verification request, the bank can store

01:13:28.820 --> 01:13:30.020
the serial number.

01:13:30.020 --> 01:13:38.800
So, it will have to maintain a database of all the serial numbers that

01:13:38.800 --> 01:13:42.080
actually have been used in payment transactions.

01:13:42.700 --> 01:13:50.040
So, as soon as a merchant or somebody sends such an electronic coin to

01:13:50.040 --> 01:13:56.740
the bank and asks for verification that this is a valid coin, the bank

01:13:56.740 --> 01:14:01.820
will say, okay, this is a valid coin, because this number is not

01:14:01.820 --> 01:14:04.500
present in my database of used coins.

01:14:05.560 --> 01:14:13.160
It will send the appropriate amount to the merchant's account, and it

01:14:13.160 --> 01:14:17.600
will store the serial number that it has now checked, will store this

01:14:17.600 --> 01:14:18.880
number in its database.

01:14:20.120 --> 01:14:27.420
That means these are coins that can be used only once, or as long as

01:14:27.420 --> 01:14:29.320
they are not verified with the bank.

01:14:31.540 --> 01:14:35.520
And after that, the merchant will send its receipt to the customer.

01:14:36.540 --> 01:14:42.500
So, the bank has to store the serial numbers of retrieved coins, but

01:14:42.500 --> 01:14:46.160
only of these retrieved coins in the database.

01:14:46.160 --> 01:14:51.340
So, if the serial number is already present, this must be a false

01:14:51.340 --> 01:14:51.780
duplicate.

01:14:52.740 --> 01:14:57.540
And in this way, we have preserved the anonymity.

01:14:58.420 --> 01:15:04.740
The bank doesn't know who actually provided this coin to the merchant,

01:15:05.760 --> 01:15:12.300
so there's no flow of information, like on the payment event, there's

01:15:12.300 --> 01:15:16.840
no flow of information between bank and customer.

01:15:17.750 --> 01:15:20.200
It's not necessary, we don't need that.

01:15:21.180 --> 01:15:24.900
So, there's no communication between customer and bank, only

01:15:24.900 --> 01:15:28.060
communication between merchant and bank.

01:15:28.540 --> 01:15:34.060
So, we have the possibility of anonymous shopping.

01:15:35.340 --> 01:15:42.980
The evaluation of eCash transaction costs are low, because you only

01:15:42.980 --> 01:15:46.620
have to get this signature from the bank.

01:15:47.440 --> 01:15:52.180
Security is achieved by using RSA public key encryption.

01:15:52.180 --> 01:15:55.460
Traceability is very low.

01:15:56.200 --> 01:15:57.600
Customer is anonymous.

01:15:59.560 --> 01:16:05.720
And the payment is undeniable.

01:16:06.440 --> 01:16:12.780
Certainly, the merchant will send a receipt to the customer, so then

01:16:12.780 --> 01:16:15.560
the merchant must have received the money.

01:16:16.560 --> 01:16:20.020
But, there is some degree of traceability.

01:16:20.440 --> 01:16:27.460
The user definitely could trace the coins that she actually generated,

01:16:27.780 --> 01:16:34.240
because the user certainly knows the serial numbers that were

01:16:34.240 --> 01:16:34.800
generated.

01:16:34.800 --> 01:16:40.680
And the user could check with the bank, could send a request to the

01:16:40.680 --> 01:16:45.000
bank and ask whether the coins that were generated have been used

01:16:45.000 --> 01:16:45.400
somewhere.

01:16:46.000 --> 01:16:47.360
This is always possible.

01:16:48.400 --> 01:16:55.680
So, if the user or the customer wants to know something about the fate

01:16:55.680 --> 01:16:57.900
of its coins, it can check with the bank.

01:16:58.320 --> 01:17:05.980
Certainly, at that moment, the anonymity is lifted, but that's on

01:17:05.980 --> 01:17:09.220
request of the customer and not on request of the bank.

01:17:10.180 --> 01:17:13.060
The problem is that we need online checking.

01:17:14.360 --> 01:17:23.260
That means the bank has to provide a database containing all used

01:17:23.260 --> 01:17:23.740
coins.

01:17:24.340 --> 01:17:31.000
This database certainly prevents misuse, but it also introduces

01:17:31.000 --> 01:17:31.600
overhead.

01:17:32.320 --> 01:17:37.540
We need this large database, and that means coins will not have a very

01:17:37.540 --> 01:17:39.600
long period of validity.

01:17:39.940 --> 01:17:45.360
They will be unvalid after some time, things like that, in order to

01:17:45.360 --> 01:17:47.780
prevent these databases from growing too large.

01:17:48.740 --> 01:17:53.920
The problem certainly is that you can only use eCash with merchants

01:17:53.920 --> 01:17:56.860
that are eCash-enabled.

01:17:58.120 --> 01:18:01.720
Another problem is transferability.

01:18:01.840 --> 01:18:02.580
What about that?

01:18:03.700 --> 01:18:07.340
Certainly, you can transfer your coins to any person.

01:18:08.240 --> 01:18:10.520
It's not bound to any fixed hardware.

01:18:10.720 --> 01:18:14.680
You just need a possibility to store electronic information.

01:18:16.040 --> 01:18:18.920
So, that is high transferability.

01:18:19.700 --> 01:18:21.800
Divisibility certainly is not provided.

01:18:22.200 --> 01:18:25.060
It's the same as we have in normal cash.

01:18:25.340 --> 01:18:30.200
It depends on the coin values that the bank is willing to validate.

01:18:33.360 --> 01:18:43.140
This system has been designed by a company called DigiCash, and it has

01:18:43.140 --> 01:18:51.800
been used by quite some banks, or at least tested by quite some banks.

01:18:52.120 --> 01:18:56.900
The Deutsche Bank actually did some major experiments with it.

01:18:58.740 --> 01:19:04.560
But, at the moment, it's not really in active use.

01:19:05.180 --> 01:19:07.980
So, another partial failure.

01:19:08.120 --> 01:19:09.040
It's a nice system.

01:19:09.720 --> 01:19:13.480
Certainly, there is this problem that you have this online checking

01:19:13.480 --> 01:19:22.140
requirement, unless you bear the risk of having received a false copy.

01:19:24.900 --> 01:19:33.720
So, some way, this system, again, was not as successful as the

01:19:33.720 --> 01:19:38.200
founders of this company, DigiCash, actually had hoped for.

01:19:40.840 --> 01:19:46.280
And people still experiment with payment systems.

01:19:46.900 --> 01:19:49.640
Another way would be to use smart cards.

01:19:51.140 --> 01:19:57.440
So, if you use a smart card, you would need a special reader for your

01:19:57.440 --> 01:20:01.400
smart card, your checking card, bank card, or whatever.

01:20:02.460 --> 01:20:11.140
So, here you would also have some type of prepaid cash on the smart

01:20:11.140 --> 01:20:15.300
card, but the systems that are in use don't provide you with the

01:20:15.300 --> 01:20:17.800
degree of anonymity that I just described.

01:20:18.480 --> 01:20:21.860
Here, you have more information on it.

01:20:22.200 --> 01:20:23.440
You have traceability on there.

01:20:23.440 --> 01:20:29.840
So, this is not for usage on the internet, but for paying in any shop,

01:20:30.380 --> 01:20:32.400
on the street, or whatever, or on the bus.

01:20:33.500 --> 01:20:41.440
It's designed to replace cash, but I already asked you last week, I

01:20:41.440 --> 01:20:45.080
guess, I think, about the degree of usage.

01:20:47.540 --> 01:20:54.000
And so, as I saw here, only very few of you use, actually, the smart

01:20:54.000 --> 01:20:54.760
cards for paying.

01:20:55.680 --> 01:20:58.020
I must confess, I didn't use it so far.

01:20:59.100 --> 01:21:07.280
So, certain transactions are done with it, but it's not really in

01:21:07.280 --> 01:21:07.980
widespread use.

01:21:09.240 --> 01:21:14.020
The advantage over standard bank cards are that, usually, we have

01:21:14.020 --> 01:21:15.680
improved security.

01:21:15.900 --> 01:21:19.540
Like, standard bank cards have been these magnetic cards without a

01:21:19.540 --> 01:21:19.760
chip.

01:21:20.140 --> 01:21:24.380
Now, also, the bank cards usually have processors on it.

01:21:24.620 --> 01:21:26.780
So, we have security on there.

01:21:26.880 --> 01:21:28.360
We have quite some memory.

01:21:31.660 --> 01:21:38.480
And the problem is that there is some secret information on there,

01:21:38.600 --> 01:21:42.720
which you shouldn't be able to manipulate as a customer.

01:21:43.120 --> 01:21:48.920
Only the bank's software should be able to put money on the bank card,

01:21:49.420 --> 01:21:54.640
or on the smart card, or these readers here should be capable of

01:21:54.640 --> 01:21:56.600
retrieving money.

01:21:59.080 --> 01:22:03.680
The problem was that severe attacks on initial versions of smart cards

01:22:03.680 --> 01:22:04.540
have been possible.

01:22:04.740 --> 01:22:09.540
I already mentioned that when I told you something about attacks to

01:22:09.540 --> 01:22:10.360
DES.

01:22:10.920 --> 01:22:12.180
I don't want to repeat that.

01:22:13.180 --> 01:22:20.740
And, therefore, the use of smart cards is also still not that

01:22:20.740 --> 01:22:21.200
widespread.

01:22:22.680 --> 01:22:31.220
Nevertheless, smart cards are the way of identification in the home

01:22:31.220 --> 01:22:37.080
banking interface standard as designed by the German Central Banking

01:22:37.080 --> 01:22:37.400
Committee.

01:22:39.000 --> 01:22:47.480
There is a series, or a sequence, or a collection of transactions

01:22:47.480 --> 01:22:56.460
designed to be done in quite a secure way using smart cards for

01:22:56.460 --> 01:22:57.220
authentication.

01:22:59.140 --> 01:23:04.100
There actually are some European standards for electronic purses.

01:23:05.260 --> 01:23:11.640
So, there is a European norm, which has been published some time ago.

01:23:12.420 --> 01:23:14.780
And what has to be normed in such a standard?

01:23:14.780 --> 01:23:19.660
Certainly, it's necessary to have some standardization, because if

01:23:19.660 --> 01:23:25.000
every company would design its own payment system, then this cannot be

01:23:25.000 --> 01:23:25.680
a success.

01:23:25.900 --> 01:23:28.340
The success can only come from standardization.

01:23:29.400 --> 01:23:33.360
And, therefore, what was standardized is the following operations.

01:23:33.360 --> 01:23:38.040
How can we actually load money on such a smart card?

01:23:38.180 --> 01:23:44.560
How can we purchase something with a smart card, like deduct money

01:23:44.560 --> 01:23:48.760
from the smart card using some piece of software that the merchant

01:23:48.760 --> 01:23:49.180
has?

01:23:50.080 --> 01:23:55.940
Then, we might have incremental purchases, like certain parts of this

01:23:55.940 --> 01:23:59.520
money have to be deducted.

01:23:59.520 --> 01:24:09.040
It must be possible to reverse purchase, like you want to invert

01:24:09.040 --> 01:24:14.800
payment, retrieve the money that just had been deducted, so it should

01:24:14.800 --> 01:24:17.380
be possible to cancel the last purchase.

01:24:17.380 --> 01:24:22.080
And something which, well, it's not that important anymore.

01:24:22.280 --> 01:24:26.460
It had been more important some years ago.

01:24:26.800 --> 01:24:28.080
Currency exchange.

01:24:28.700 --> 01:24:33.320
Certainly, we still have some different currencies, at least in

01:24:33.320 --> 01:24:33.600
Europe.

01:24:33.860 --> 01:24:38.480
We mainly have the euro, but we still have the exchange requirements

01:24:38.480 --> 01:24:39.820
between euro and dollars.

01:24:39.820 --> 01:24:45.060
And if you would use your, or between euro and British pound.

01:24:45.740 --> 01:24:52.160
So, what you would like is to be able to use your smart card in

01:24:52.160 --> 01:24:58.560
countries where the euro is a currency, and also in Britain.

01:24:59.260 --> 01:25:05.020
And there should be an automatic exchange between the two currencies

01:25:05.020 --> 01:25:06.260
on your smart card.

01:25:06.260 --> 01:25:10.960
If you want to see more about this standardization, just look at the

01:25:10.960 --> 01:25:18.420
server of this commission that is responsible for the electronic

01:25:18.420 --> 01:25:19.480
specification.

01:25:21.660 --> 01:25:28.720
Different architectures have been designed for these payment systems.

01:25:29.440 --> 01:25:36.020
Some just use software for payment transactions.

01:25:36.020 --> 01:25:39.760
For instance, SET, for example, is something which is only software

01:25:39.760 --> 01:25:40.260
based.

01:25:40.520 --> 01:25:47.080
You have the user, and you have this secret information on your PC.

01:25:47.780 --> 01:25:55.660
But certainly, the PC can be attacked by other persons.

01:25:55.660 --> 01:26:03.040
So, one tries to take the secret information from the PC that might be

01:26:03.040 --> 01:26:04.500
accessible to others.

01:26:05.400 --> 01:26:12.340
Then we have here the smart card only possibility where the secret

01:26:12.340 --> 01:26:15.940
information and the computations are performed on the smart card.

01:26:15.940 --> 01:26:18.820
The Java card is something which is used here.

01:26:19.200 --> 01:26:23.740
You have extensive processing on the smart card, which certainly will

01:26:23.740 --> 01:26:29.840
take some time as soon as you require strong, or use a strong

01:26:29.840 --> 01:26:30.460
cryptography.

01:26:32.040 --> 01:26:37.860
Protocols are still here in the PC, and the user has to identify

01:26:37.860 --> 01:26:40.920
himself to the PC.

01:26:40.920 --> 01:26:45.360
This can be attacked by some other persons.

01:26:45.360 --> 01:26:51.180
Then we have this other way here of identification of the user to the

01:26:51.180 --> 01:26:54.500
system using some extra device.

01:26:55.400 --> 01:27:00.180
So, secret key computation and protocols all done on this extra

01:27:00.180 --> 01:27:00.740
device.

01:27:00.740 --> 01:27:09.620
And here you have a smart card reader with keyboard and screen, a

01:27:09.620 --> 01:27:16.000
smart card reader, and these cryptographic protocols are not executed

01:27:16.000 --> 01:27:17.460
anymore on the PC.

01:27:17.700 --> 01:27:21.740
So, this would be the ultimate security for these systems.

01:27:22.780 --> 01:27:30.080
Here is a brief listing of different payment protocols, online

01:27:30.080 --> 01:27:37.200
payments, offline payments, traceable, untraceable, and here,

01:27:37.560 --> 01:27:45.180
certainly, we have here the CNIP standard, which is offline payment

01:27:45.180 --> 01:27:47.080
method, but traceable.

01:27:47.080 --> 01:27:56.480
We have the untraceable e-cash system, and, well, there are also other

01:27:56.480 --> 01:27:57.220
methods.

01:27:57.420 --> 01:28:04.260
I couldn't present to you all the methods that are available in these

01:28:04.260 --> 01:28:05.480
electronic payment systems.

01:28:05.480 --> 01:28:09.960
I just wanted to mention there's one more system, which I didn't

01:28:09.960 --> 01:28:12.680
mention on these slides, which is, whoops,

01:28:16.360 --> 01:28:18.300
I didn't want to do this.

01:28:22.140 --> 01:28:26.780
So, let's go back to the presentation mode.

01:28:29.380 --> 01:28:39.200
I wanted to just mention briefly that there is one other method called

01:28:39.200 --> 01:28:41.880
Paybox.

01:28:45.430 --> 01:28:51.030
Paybox is a system that uses your Handy for payment purposes,

01:28:51.390 --> 01:28:56.430
something which came into use, well, something like one and a half

01:28:56.430 --> 01:28:58.710
years ago, or almost two years ago.

01:28:58.710 --> 01:29:04.790
And just these days, there was a message on the internet that Paybox

01:29:04.790 --> 01:29:05.990
ended its service.

01:29:06.490 --> 01:29:16.510
So, it was a nice attempt to use mobile phones for payment

01:29:16.510 --> 01:29:25.550
transactions, but as I mentioned for e-cash, for SCT, all these nice

01:29:25.550 --> 01:29:30.150
electronic ways of payment run into problems in the moment.

01:29:31.270 --> 01:29:37.630
So, we have quite a few nice ideas, but it's not that clear what will

01:29:37.630 --> 01:29:39.150
happen to these nice ideas.

01:29:39.290 --> 01:29:41.790
I think they will be used some later time.

01:29:42.130 --> 01:29:47.570
Maybe we still have to look for the ultimate electronic payment

01:29:47.570 --> 01:29:56.650
system, which doesn't produce high overhead costs and therefore can be

01:29:56.650 --> 01:29:58.830
put into widespread use.

01:29:58.830 --> 01:30:01.070
Okay, thanks for your attention today.

01:30:01.570 --> 01:30:02.470
See you again next week.

01:30:02.590 --> 01:30:06.190
Next week, I will present to you a few things about firewalls, and

01:30:06.190 --> 01:30:08.350
that will be the end of this course.

01:30:08.770 --> 01:30:12.050
And I will mention at this moment already that certainly the

01:30:12.050 --> 01:30:18.810
information that I present to you next week will not be information

01:30:18.810 --> 01:30:23.150
that I will ask you two weeks from now in the final exam.

01:30:23.150 --> 01:30:30.230
So, I think it's fair to ask you only to know things that have been

01:30:30.230 --> 01:30:32.310
presented up to this moment.

01:30:32.790 --> 01:30:37.890
Next week's information will be relevant for the exam at the end of

01:30:37.890 --> 01:30:42.770
the summer term, but not for the exam at the end of this term.

01:30:43.050 --> 01:30:44.190
Okay, thanks for your attention.

01:30:44.710 --> 01:30:45.410
See you next week.