WEBVTT 00:09.820 --> 00:12.440 All right, good morning everyone. 00:25.910 --> 00:30.470 I have one administrative remark, that is that on Friday we have the 00:30.470 --> 00:32.310 last exercise with the last quiz. 00:33.150 --> 00:37.630 So this is your last chance to get the bonus, if you haven't got it 00:37.630 --> 00:37.910 yet. 00:40.590 --> 00:46.210 So what did we do in the last course, in the last lecture? 00:47.510 --> 00:53.150 We talked about electronic payment systems, a new chapter. 00:54.710 --> 00:59.210 And we saw that there are different kinds of electronic payment 00:59.210 --> 00:59.750 systems. 00:59.750 --> 01:07.590 The simplest system is just a two-party system, where you can use the 01:07.590 --> 01:13.030 money only in one particular shop, where you have usually prepaid some 01:13.030 --> 01:16.910 amount of money, and then you can store it electronically and use it 01:16.910 --> 01:17.210 later. 01:18.190 --> 01:25.150 Three -party systems, where we have the bank, so you give money, you 01:25.150 --> 01:28.870 prepay money to the bank, you give back electronic money, you can use 01:28.870 --> 01:34.150 that electronic money with all the participating merchants, but the 01:34.150 --> 01:42.370 merchant cannot use this money, he only has to redeem it back to real 01:42.370 --> 01:45.830 money, convert it back to real money at the bank. 01:46.590 --> 01:52.570 And ideally, we would like to have an open-loop system, just like the 01:52.570 --> 01:59.310 real money, that I can transfer from one person to the other, and it 01:59.310 --> 02:02.930 can be a long chain until the money goes back to a bank. 02:07.450 --> 02:11.970 We looked at a couple of criteria that are important for electronic 02:11.970 --> 02:12.810 payment systems. 02:13.610 --> 02:15.190 Security, of course. 02:16.350 --> 02:22.150 Transaction costs, particularly important if you have micropayments, 02:22.390 --> 02:30.010 so if you pay for reading an article in a newspaper, which is maybe 02:30.010 --> 02:38.230 only a few cents, or even for viewing websites, or for getting real 02:38.230 --> 02:41.610 -time stock market information, or things like that. 02:41.610 --> 02:46.750 So, if you only pay a few cents, of course the transaction costs 02:46.750 --> 02:48.550 should be much less than a few cents. 02:51.830 --> 02:56.870 Traceability has two sides, so on the one hand, you would like to have 02:56.870 --> 03:03.190 traceability, so that you can detect fraud, and find out who did the 03:03.190 --> 03:05.270 wrong thing with the money, who tried to cheat. 03:05.890 --> 03:09.630 On the other hand, of course, from a consumer side, you would like to 03:09.630 --> 03:12.170 have anonymity, so no traceability. 03:13.850 --> 03:17.630 You don't want that the bank, or whoever knows what you bought at 03:17.630 --> 03:21.870 which store, and how much money you spent where, you would like to 03:21.870 --> 03:24.070 keep it anonymous. 03:26.450 --> 03:34.070 Online checking requirement is the question of whether if you buy with 03:34.070 --> 03:38.570 electronic money at some shop, this shop can trust the money, or 03:38.570 --> 03:44.190 whether it needs an online connection to the issuing companies, or 03:44.190 --> 03:48.710 usually the bank, to confirm that the money is actually valid and has 03:48.710 --> 03:49.770 not been used before. 03:52.110 --> 03:53.710 Acceptability is an issue, of course. 03:54.710 --> 03:56.670 Where can you use this electronic money? 03:57.110 --> 03:59.350 Transferability, as I said, is a difficult issue. 04:01.010 --> 04:07.090 If you want to transfer the money from one person to another, without 04:07.090 --> 04:09.850 involvement of the bank, that's difficult. 04:10.430 --> 04:16.190 And divisibility, with real money, with coins, you can't divide them, 04:16.190 --> 04:21.830 it doesn't make sense to cut a two euro coin into two pieces, to have 04:21.830 --> 04:26.070 one euro, but with electronic money you think it would be ideally 04:26.070 --> 04:28.970 possible to divide money into smaller pieces. 04:29.190 --> 04:29.370 Yes? 04:38.820 --> 04:43.320 There was the question whether I could give an example for an open 04:43.320 --> 04:43.940 loop system. 04:45.380 --> 04:48.940 Do you mean one that is actually implemented? 04:48.940 --> 04:52.120 I don't know of any that are implemented. 04:54.740 --> 05:01.260 So far, in the last lecture, all we discussed was basically secure 05:01.260 --> 05:06.260 communication, using credit cards for payments. 05:06.880 --> 05:12.760 What we will discuss today is a system that is more close to true 05:12.760 --> 05:18.760 electronic money, but it's not an open loop system, so you cannot give 05:18.760 --> 05:19.860 the money to other people. 05:20.780 --> 05:27.540 There are such systems that have been thought of theoretically, but I 05:27.540 --> 05:30.520 don't know of any implemented system that is open loop. 05:33.440 --> 05:35.200 But it's possible to do it. 05:36.900 --> 05:42.020 OK, I'm not going into the details, we discussed them two weeks ago. 05:54.920 --> 06:00.520 OK, we then discussed in more detail the credit card systems, which 06:00.520 --> 06:06.360 are actually the kind of system that is most widely used today. 06:07.360 --> 06:12.780 Almost everyone, at least in developed countries, has a credit card, 06:12.780 --> 06:14.840 and it's very easy to use. 06:15.960 --> 06:18.640 You know how to use it from going to shops. 06:18.780 --> 06:21.660 You just show your credit card, they take the number, and then you 06:21.660 --> 06:21.940 sign. 06:23.240 --> 06:28.220 And you can use the credit card also over the internet. 06:28.660 --> 06:31.820 All the merchant needs is basically your credit card number. 06:32.380 --> 06:38.200 What they usually also require is this so-called secret number on the 06:38.200 --> 06:44.120 back of your card, that is not transmitted in the transactions if you 06:44.120 --> 06:44.780 go to a shop. 06:45.320 --> 06:47.640 But basically all they need is a number. 06:50.020 --> 06:54.360 And of course that means there is a certain risk involved, because 06:54.360 --> 06:58.380 everyone who has your credit card number could potentially use it in 06:58.380 --> 06:59.980 the internet to buy things. 07:00.460 --> 07:07.040 So you would want to protect your number at least for the 07:07.040 --> 07:13.920 communication, and of course you can use something like SSL, Secure 07:13.920 --> 07:19.100 Socket Layer, to have secured communication and encrypted 07:19.100 --> 07:19.920 communication. 07:21.180 --> 07:24.740 And that's today I think basically standard. 07:25.540 --> 07:29.300 If you go to websites where you have to pay, you usually transfer to a 07:29.300 --> 07:35.860 web address that starts with HTTPS, and that's exactly the SSL 07:35.860 --> 07:36.440 protocol. 07:37.860 --> 07:43.980 You still have the problem that the merchant of course gets all your 07:43.980 --> 07:47.480 credit card information, and could potentially reuse it. 07:47.900 --> 07:55.200 And the only protection is that you have a limited liability for fraud 07:55.200 --> 07:56.580 when using credit cards. 07:56.640 --> 08:02.580 So the credit card companies charge pretty hefty fees if you are using 08:02.580 --> 08:08.000 your credit card, between 2% and 3%, 4% of what you buy. 08:09.060 --> 08:12.280 And so they cover the fraud basically from that. 08:12.440 --> 08:13.700 So they just take the risk. 08:14.160 --> 08:18.020 And of course they have elaborate mechanisms to try to detect fraud. 08:18.540 --> 08:26.100 So if you are using your credit card mostly in Europe, mostly to buy 08:26.100 --> 08:32.100 in certain shops, and then you have some unusual usage of your credit 08:32.100 --> 08:39.520 card, so maybe suddenly in Mexico or so, then they will try to 08:39.520 --> 08:43.060 immediately detect that and call you and ask, did you really do that 08:43.060 --> 08:46.380 transaction, or maybe was it a fraud. 08:47.600 --> 08:51.200 So they have sophisticated algorithms to try to detect fraud, but 08:51.200 --> 08:53.500 nevertheless, fraud happens. 08:53.500 --> 08:58.400 I have no numbers on how much that is, and everyone has to pay it 08:58.400 --> 08:59.980 basically through the fees. 09:02.820 --> 09:08.720 We looked in more detail at one more elaborate protocol, which was the 09:08.720 --> 09:13.620 SET, secure electronic transaction protocol, that was specifically 09:13.620 --> 09:20.860 designed for using the credit card over the internet. 09:23.960 --> 09:28.840 And the additional feature that SET provides is confidentiality. 09:29.380 --> 09:36.640 The information about the payment is not shown to the merchant, and 09:36.640 --> 09:39.900 the information about the order is not shown to the bank. 09:40.680 --> 09:44.520 So the bank doesn't have to know what you ordered, and the merchant 09:44.520 --> 09:46.560 doesn't have to know your credit card information. 09:47.560 --> 09:58.860 So these are in separate messages, and the trick there was somehow to 09:58.860 --> 10:03.800 ensure that the payment information and the order information, 10:04.320 --> 10:09.180 although the merchant and the bank see different information, have 10:09.180 --> 10:12.260 access to different information, they can still confirm that the 10:12.260 --> 10:15.600 information belongs together and is the right information. 10:15.600 --> 10:20.100 And the trick here was the dual signature. 10:21.460 --> 10:24.820 You remember how to do digital signatures? 10:26.380 --> 10:30.540 Usually for a digital signature you calculate the hash value of a 10:30.540 --> 10:36.080 message, and then you encrypt the hash value with your private key of 10:36.080 --> 10:44.400 an asymmetric encryption method, and thereby that makes sure that the 10:44.400 --> 10:48.520 message cannot be modified, and that the message is really from you, 10:48.600 --> 10:49.980 so it's authenticated. 10:52.000 --> 10:56.940 The idea of the dual signature is that you have these two pieces of 10:56.940 --> 11:00.580 information, the order information and the payment information, you 11:00.580 --> 11:06.120 calculate a message digest of both, and then you calculate a digest of 11:06.120 --> 11:10.640 these two digests, and you sign that digest, so you encrypt that 11:10.640 --> 11:12.880 digest with your secret key. 11:14.660 --> 11:24.240 And therefore, the merchant, for example, can look at the order 11:24.240 --> 11:29.800 information and verify that the order information is correct, and if 11:29.800 --> 11:37.240 he has the order information and the message digest from the payment 11:37.240 --> 11:42.320 information, he doesn't have to have the payment information to look 11:42.320 --> 11:46.240 at and to verify the overall integrity of the message. 11:46.860 --> 11:48.880 And the same thing vice versa for the bank. 11:49.320 --> 11:52.780 The bank only needs the payment information and the message digest of 11:52.780 --> 11:55.200 the order information. 11:57.600 --> 12:02.240 And then you probably remember all these nice little pictures. 12:05.040 --> 12:10.760 Besides of the dual signature, it was more or less always the same 12:10.760 --> 12:11.260 story. 12:13.740 --> 12:19.980 You use that typical scheme for secure communication, meaning that you 12:19.980 --> 12:25.120 generate a random session key, you use that session key to encrypt 12:25.120 --> 12:33.340 your message, and then you encrypt the session key with the public key 12:33.340 --> 12:41.360 of the receiving side, and on the receiving side then you can undo all 12:41.360 --> 12:48.160 this encryption, you can, with the private key, encrypt the message 12:48.160 --> 12:57.120 key, the session key, encrypt the message, and oh, so I forgot the 12:57.120 --> 13:01.920 digital signature of course, that also comes in then here with this 13:01.920 --> 13:02.960 dual signature. 13:03.660 --> 13:06.960 I'm not going into the details again, I think there was long enough 13:06.960 --> 13:12.220 last time, lots of nice pictures, but basically it's always the same 13:12.220 --> 13:14.520 idea. 13:14.520 --> 13:19.140 You send several messages and you send them in a secure way. 13:42.760 --> 13:51.000 This is a somewhat old slide about cybercash, so we want to now talk 13:51.000 --> 13:56.960 about different forms of electronic money, and cybercash actually 13:56.960 --> 14:01.680 doesn't exist anymore, most of the companies that were founded in the 14:01.680 --> 14:07.540 dot -com boom tried to establish electronic money, were bought by some 14:07.540 --> 14:10.500 other companies, and there are very few that are remaining. 14:19.080 --> 14:27.640 The one that is one of the most popular is PayPal, I'm sure you have 14:27.640 --> 14:28.180 heard of it. 14:28.780 --> 14:34.920 PayPal itself has been bought by eBay, so they advertise it a lot to 14:34.920 --> 14:39.940 be used for eBay transactions, but you can also use it in other shops, 14:40.060 --> 14:41.540 many shops use that. 14:43.040 --> 14:52.640 Another popular, similar mechanism is click-and-buy, that's actually 14:52.640 --> 14:55.860 more popular in Europe, PayPal is more popular in the US. 14:55.860 --> 15:02.780 And I tried hard to find information on exactly the protocols that 15:02.780 --> 15:05.420 they use, but I couldn't. 15:06.500 --> 15:08.240 Is anyone here using PayPal? 15:10.120 --> 15:12.860 Okay, quite a few, so maybe you can... 15:13.680 --> 15:18.620 I have never used it, maybe you can briefly explain how PayPal works. 15:46.670 --> 15:52.350 Okay, so that was also what I think I found out, but I wasn't sure, 15:52.890 --> 16:00.390 that basically PayPal works, and also click-and-buy, that you go to a 16:00.390 --> 16:06.710 shop, you buy something there, and then once you have entered, or you 16:06.710 --> 16:10.290 have decided what you want to buy, you get redirected to the PayPal 16:10.290 --> 16:11.430 site, right? 16:11.430 --> 16:16.810 And there you actually do the transaction, so you enter your PayPal 16:16.810 --> 16:26.210 password or passphrase, and confirm the transaction, and then PayPal 16:26.210 --> 16:32.150 starts the actual money transfer, and checks whether you have enough 16:32.150 --> 16:35.270 money on your bank account, and transfers it to the merchant, and 16:35.270 --> 16:43.050 tells the merchant, okay, fine, you got the money, is that right? 16:44.130 --> 16:50.230 Okay, so it's basically, I think, compared to credit card payments, 16:50.450 --> 16:57.330 the advantage is that the information on your credit card is not given 16:57.330 --> 17:07.110 to the merchant, but it's only with PayPal, and you have this 17:07.110 --> 17:15.030 additional keyword that you have to enter in order to confirm the 17:15.030 --> 17:16.090 purchase. 17:16.910 --> 17:18.290 I think these are the advantages. 17:19.090 --> 17:22.450 So that's PayPal, and I think click-and-buy works just the same way. 17:24.570 --> 17:29.630 So this, I think, is actually old and not interesting anymore. 17:33.740 --> 17:38.500 There's a company in Karlsruhe that's called Fun, and they have a 17:38.500 --> 17:54.380 similar system that doesn't have an extra website where you do the 17:54.380 --> 18:00.280 payment, just like PayPal, but they use the home banking system of 18:00.280 --> 18:01.460 your bank. 18:01.800 --> 18:08.840 You all have used online transactions, I guess, with your bank 18:08.840 --> 18:15.240 account, with the bank, and basically what Fun allows you to do is use 18:15.240 --> 18:20.920 exactly that interface to transfer money to the merchant, and then it 18:20.920 --> 18:23.920 will tell the merchant, okay, the person has transferred you the 18:23.920 --> 18:25.720 money, you can send him the goods. 18:27.420 --> 18:33.480 So that's a simple idea that avoids having to set up yet another 18:33.480 --> 18:35.160 interface. 18:49.840 --> 18:53.360 The question was whether this company is working together with the 18:53.360 --> 18:55.860 bank or acts as a man in the middle. 18:58.980 --> 19:00.740 I'm not entirely sure. 19:02.660 --> 19:07.620 I know there are those payment methods where they offer to let you pay 19:07.620 --> 19:11.700 online banking and then they ask you for your PIN number and 19:11.700 --> 19:14.560 transaction number, but not on the bank home page, right? 19:14.920 --> 19:18.780 No, no, I think you are redirected to the bank home page, so they have 19:18.780 --> 19:22.760 to somehow cooperate with the banks, but I'm not sure, I think the 19:22.760 --> 19:28.480 banks have some interface to their system that allows you to use some 19:28.480 --> 19:35.460 more sophisticated programs that directly plug into the bank software. 19:36.860 --> 19:40.440 And I assume that they use that, but I have not used that system 19:40.440 --> 19:40.740 either. 19:47.300 --> 19:52.800 Okay, now eCash is more closer to the real electronic money 19:56.020 --> 20:01.320 that allows you to really generate new money, electronic money. 20:02.300 --> 20:07.820 The coins exist as a file only, independent of credit cards and other 20:07.820 --> 20:10.100 means of money transfer. 20:11.140 --> 20:17.020 And the aspect that is particularly interesting here is that it's 20:17.020 --> 20:18.040 completely anonymous. 20:19.780 --> 20:26.460 This is an online solution, which means that the merchant who accepts 20:26.460 --> 20:29.560 the money has to have an online connection to the bank and check 20:29.560 --> 20:30.800 whether the money is valid. 20:33.620 --> 20:37.600 There are also offline solutions and open loop solutions, but these 20:37.600 --> 20:41.900 are significantly more complex, because it's much more difficult to 20:41.900 --> 20:42.600 detect fraud. 20:42.600 --> 20:48.860 And so I will restrict myself here in this course on this simplistic 20:48.860 --> 20:55.200 online solution, but it actually has been implemented and has been 20:55.200 --> 20:56.060 used. 20:56.140 --> 21:01.220 I'm not sure whether it's still used, but several banks offer this 21:01.220 --> 21:01.900 kind of money. 21:05.400 --> 21:10.120 And what you get is basically some electronic coins that represent a 21:10.120 --> 21:11.200 certain amount of money. 21:12.660 --> 21:18.440 The key ideas are that you use, of course, RSA, public key encryption, 21:19.040 --> 21:23.100 and what is called a blind digital signature. 21:26.180 --> 21:29.340 In order to achieve this anonymity, 21:32.560 --> 21:39.380 you cannot allow the bank to see the serial number of the coins that 21:39.380 --> 21:42.240 it signs, that it authenticates. 21:43.700 --> 21:45.440 That's called a blind signature. 21:45.760 --> 21:51.080 The bank has to sign and confirm the validity of this coin without 21:51.080 --> 21:52.980 seeing the serial number. 21:53.780 --> 21:55.940 And we'll have a look at how this works. 21:59.530 --> 22:01.910 So, eCash is a closed-loop system. 22:02.150 --> 22:03.070 We have three parties. 22:03.330 --> 22:09.530 The bank, which issues the electronic coins and changes real money 22:09.530 --> 22:10.590 into eCash. 22:12.150 --> 22:16.930 The customers, who have an account at some eCash bank, where they can 22:16.930 --> 22:19.310 withdraw eCash and deposit it. 22:20.310 --> 22:22.690 And the merchant, who accepts the eCash. 22:23.830 --> 22:32.730 The coins are actually generated by software on the customer's 22:32.730 --> 22:33.110 computer. 22:34.010 --> 22:35.910 That's usually called a cyber wallet. 22:36.630 --> 22:40.230 That's great, a wallet that can generate money. 22:43.910 --> 22:49.210 This software generates a random serial number. 22:50.730 --> 22:56.850 That has to be sufficiently long to guarantee, in quotes, uniqueness. 22:57.490 --> 23:01.030 Because, of course, you cannot guarantee it for 100%, but if you have 23:01.030 --> 23:04.950 a, I don't know, 100-digit number, the probability that someone else 23:04.950 --> 23:10.670 will generate the same serial number is very, very, very, very small. 23:10.670 --> 23:16.650 So, that's a risk that you take, because the serial number will 23:16.650 --> 23:22.050 identify your coin and make sure that you can use the coin only once. 23:22.570 --> 23:25.730 If someone else tries to use the same coin with the same serial 23:25.730 --> 23:28.790 number, that would be detected and would not be accepted. 23:29.430 --> 23:34.210 So, if by chance you generate the same serial number as someone else, 23:34.250 --> 23:37.990 who has already used the coin with that serial number, then you cannot 23:37.990 --> 23:38.690 use your coin. 23:39.310 --> 23:41.890 But, that's a risk you have to take. 23:42.150 --> 23:46.130 And, as I said, if you make the serial number sufficiently long, the 23:46.130 --> 23:49.610 probability is sufficiently small that this actually happens. 23:52.510 --> 24:03.910 So, the software also, well, you can decide on the desired coin value. 24:05.830 --> 24:11.990 Usually, the bank offers you certain values that you can choose. 24:13.510 --> 24:21.350 And then, you send the serial number, but in a hidden way, so that the 24:21.350 --> 24:27.310 bank cannot see it, and the coin value to the bank, encrypted with the 24:27.310 --> 24:33.850 customer's private key, so that the bank knows, okay, this is really 24:33.850 --> 24:35.790 from that customer. 24:41.740 --> 24:52.180 The bank will check that the coin is really by the customer. 24:52.580 --> 24:57.920 It will validate the coin by this blind signature, which I'll explain 24:57.920 --> 24:59.140 in a minute, in more detail. 25:02.480 --> 25:06.400 And one important part is that the validation is value-specific. 25:07.360 --> 25:12.820 So, the bank basically has different blind signatures depending on the 25:12.820 --> 25:13.780 value of the coin. 25:14.880 --> 25:21.320 So, it will sign a 2-euro coin with a different signature than a 5 25:21.320 --> 25:24.380 -euro coin, and that with a different signature from a 10-euro coin. 25:24.880 --> 25:30.720 And that basically makes sure that you can only use it with that 25:30.720 --> 25:31.540 particular value. 25:32.380 --> 25:36.660 Then, of course, the bank deducts the corresponding amount from the 25:36.660 --> 25:40.660 customer's account, and sends the validated coin back to the customer, 25:41.180 --> 25:45.420 using the customer's public key, so that no one else but the customer 25:45.420 --> 25:51.140 can retrieve the coin, because that is now a valuable. 25:54.260 --> 26:01.880 The customer software makes the serial number visible again, and adds 26:01.880 --> 26:09.080 the validating digital signature from the bank, that basically also 26:09.080 --> 26:11.400 shows the value of that coin. 26:15.610 --> 26:18.250 So, let's have a look at this blind signature. 26:18.890 --> 26:24.150 Let's say Alice wants to have Bob, so the bank, sign a message that 26:24.150 --> 26:27.730 the bank should not know the serial number. 26:27.870 --> 26:31.530 Because if the bank would know the serial number, and you go to a 26:31.530 --> 26:35.230 merchant, you buy something, the merchant will check, will send the 26:35.230 --> 26:39.370 serial number to the bank to check whether this money has been used 26:39.370 --> 26:39.810 before. 26:40.890 --> 26:46.250 Then the bank would know, ah, I have given this serial number to 26:46.250 --> 26:53.410 Alice, and now I get the serial number back from this bookstore, so I 26:53.410 --> 26:55.190 know Alice bought some books at this bookstore. 26:55.570 --> 26:57.810 And that's exactly what we want to avoid. 26:57.990 --> 27:02.450 So the bank should not know the serial number before the coin is 27:02.450 --> 27:03.610 actually spent. 27:04.510 --> 27:05.230 So, 27:08.790 --> 27:15.330 the idea is that Alice hides the message in a so-called blinding 27:15.330 --> 27:20.870 envelope, and Bob signs this envelope without actually opening it, 27:24.470 --> 27:28.270 and then Alice can take the signed message from the envelope. 27:29.070 --> 27:37.530 You can imagine this as maybe carbonated paper, you have a carbonated 27:37.530 --> 27:44.050 envelope, you put the message in there, close the envelope, the bank 27:44.050 --> 27:48.170 can sign on the envelope, but because it's carbonated, it will print 27:48.170 --> 27:50.250 through the message. 27:50.750 --> 27:54.150 When you get the envelope back, you open it, and you have a signed 27:54.150 --> 27:54.690 message. 27:54.690 --> 27:57.190 Now, algorithmically, 28:00.270 --> 28:02.070 this is done as follows. 28:06.030 --> 28:10.430 C and D be Bob's public and private keys. 28:11.890 --> 28:13.990 Then Alice chooses a number, 28:17.430 --> 28:23.250 a number R which is prime with respect to N. 28:26.380 --> 28:35.040 And the assumption is also that the message M is smaller than N. 28:36.680 --> 28:47.720 And then Alice sends Bob a hidden message, M', which is this random 28:47.720 --> 29:00.060 number R to the power of C, which is Bob's public key, times M modulo 29:00.060 --> 29:00.380 N. 29:02.740 --> 29:11.040 Okay, Bob signs that message, so he signs by using his private key of 29:11.040 --> 29:19.460 course, so he calculates M' to the power of D, his private key, modulo 29:19.460 --> 29:19.840 N. 29:21.220 --> 29:26.480 But that's of course, because M' is R to the power of C times M, so we 29:26.480 --> 29:34.200 have R to the power of C, M to the power of D, modulo N, and you know 29:34.200 --> 29:39.380 that R to the C to the D is exactly R. 29:39.380 --> 29:44.120 That's the idea of RSA encryption, right? 29:44.200 --> 29:49.420 If you take it to the power of your private key and then your public 29:49.420 --> 29:53.480 key, or vice versa, you just get back the original message. 29:53.480 --> 29:58.880 So that's equal to R times M to the power of D. 30:00.380 --> 30:03.760 M to the power of D is exactly what you want to have. 30:04.240 --> 30:10.620 That's the message encrypted with the bank's private key. 30:11.720 --> 30:14.580 So that only the bank could actually have signed it. 30:15.440 --> 30:20.460 And now you have to remove this R, but that's easy, that's impossible 30:20.460 --> 30:25.860 for the bank, because the bank doesn't know R, but that's easy for 30:25.860 --> 30:32.840 Alice, it just has to divide this U' by R, modulo N, and then it gets 30:32.840 --> 30:36.840 the message without that hiding factor again. 30:39.860 --> 30:44.740 And the bank had no opportunity to actually see the message, because 30:44.740 --> 30:54.720 it only operated on this message M', which was made invisible, so to 30:54.720 --> 30:59.460 say, by adding this random number in front. 31:00.800 --> 31:03.980 So that's a very smart, nice idea. 31:11.960 --> 31:16.920 And so the key point is, the bank doesn't know the message, but any 31:16.920 --> 31:22.200 other person can now verify that Bob or the bank has actually signed 31:22.200 --> 31:27.540 the message, because all you have to do is look up the public key of 31:27.540 --> 31:35.140 the bank, encrypt this U, or decrypt it with the bank's public key, 31:35.860 --> 31:43.780 then you get M, and you can check whether M really corresponds to the 31:43.780 --> 31:49.000 message that you claim to be, so the calculated M and the M that was 31:49.000 --> 31:53.340 sent along with it, and then you can compare these two, and if they 31:53.340 --> 31:57.080 are identical, then Bob has really signed this message. 31:57.880 --> 31:58.560 Okay, 32:03.000 --> 32:04.280 this is the idea again. 32:06.020 --> 32:12.740 The customer generates these coins, puts them in the envelope, sends 32:12.740 --> 32:17.400 the envelope to the bank, the bank signs them, and the customer 32:17.400 --> 32:19.700 removes them from the envelope again. 32:32.990 --> 32:37.310 Again, the bank has different key pairs for every coin value. 32:38.670 --> 32:45.150 That's the trick to make sure that the customer doesn't send you coins 32:45.150 --> 32:50.190 that have, let's say, this is a 100 euro coin, but tells the bank I 32:50.190 --> 32:51.530 have sent you a 2 euro coin. 32:52.610 --> 32:58.210 So the bank will only sign it with the 2 euro signature, and it will 32:58.210 --> 32:59.910 be only valid for 2 euros. 32:59.910 --> 33:05.180 But why would the bank sign it? 33:32.370 --> 33:37.910 And it can only be validated as a 5 euro coin, because only the 5 euro 33:37.910 --> 33:41.070 public key will work on that. 33:42.470 --> 33:46.090 And if the customer tells the merchant here this is a 100 euro coin, 33:46.950 --> 33:52.450 the merchant will try to validate it with the 100 euro public key, and 33:52.450 --> 33:55.090 that will not work, and therefore he will reject it. 33:55.090 --> 33:57.210 So it's safe. 33:57.370 --> 34:04.010 Only the serial number is hidden, but the value of the coin is given 34:04.010 --> 34:05.450 by the signature. 34:08.510 --> 34:11.010 And the bank doesn't have to know the serial number. 34:11.010 --> 34:11.690 OK, 34:21.100 --> 34:28.280 so the electronic coin consists of serial number, signature, and the 34:28.280 --> 34:34.240 signing bank's certificate, so that everyone can actually verify that 34:34.240 --> 34:35.740 this is really signed by the bank. 34:41.840 --> 34:50.120 Now if you want to buy something with eCash, the merchant sends you a 34:50.120 --> 34:53.880 payment request, and you send the coins to the merchant. 34:53.880 --> 35:01.000 The merchant will have to check online with the eCash bank, so he will 35:01.000 --> 35:05.460 send these coins to the bank. 35:06.160 --> 35:11.440 The bank can verify also that it signed these coins, it can verify the 35:11.440 --> 35:16.720 value of these coins, and it will then check against fraud. 35:16.720 --> 35:22.720 So it stores all the coins, all the serial numbers that it received, 35:22.940 --> 35:24.080 in a large database. 35:24.720 --> 35:28.460 It will check whether this particular serial number has been used 35:28.460 --> 35:28.900 before. 35:29.640 --> 35:32.020 If it has already been used, then it's rejected. 35:32.260 --> 35:36.400 If it has not been used, it's accepted, because the bank knows, OK, I 35:36.400 --> 35:41.620 have signed it, so I have received the money for it, and no one else 35:41.620 --> 35:44.020 has used that number before. 35:46.560 --> 35:50.340 If the customer would like to spend this money several times, of 35:50.340 --> 35:54.180 course it would always have the same serial number, and it would be 35:54.180 --> 35:54.620 rejected. 35:59.530 --> 36:05.770 OK, and so the bank can, if the serial number is not in its database 36:05.770 --> 36:12.650 already, it will verify the money, and the merchant can send the goods 36:12.650 --> 36:14.550 or the receipt to the customer. 36:19.060 --> 36:21.520 OK, I already sent that. 36:23.460 --> 36:23.740 So, 36:31.120 --> 36:39.640 eCash has lower transaction costs, it is quite secure, the 36:39.640 --> 36:43.520 possibilities of fraud are small. 36:45.400 --> 36:53.340 It's anonymous for the customer, so the customer, the bank doesn't 36:53.340 --> 36:55.760 know what the customer actually buys. 37:04.750 --> 37:13.790 And at the same time, the customer could ask the bank to check whether 37:13.790 --> 37:17.530 this particular serial number has already been used, and where it has 37:17.530 --> 37:24.590 been used, so he might demand traceability if he suspects fraud. 37:27.670 --> 37:37.370 We have this online checking, which is maybe expensive, that's the 37:37.370 --> 37:40.930 most expensive part of the transaction costs, I guess, because you 37:40.930 --> 37:42.290 have to have an online connection. 37:42.290 --> 37:49.590 And you have to check in a database containing all used coins, so if 37:49.590 --> 37:52.790 everyone would use these coins, these databases might become quite 37:52.790 --> 37:56.670 large and computationally demanding. 37:58.390 --> 38:06.970 Acceptability, we'll see that a number of banks have used eCash or 38:06.970 --> 38:14.510 provided a lot for eCash, but I'm not aware of any shops that actually 38:14.510 --> 38:17.910 allow you to use eCash. 38:20.810 --> 38:25.910 Transferability, so in principle, you could take these coins and give 38:25.910 --> 38:31.870 them to a friend, but the problem would be your friend would have to 38:31.870 --> 38:35.970 trust you that you are not using these coins anywhere else, that it's 38:35.970 --> 38:39.690 not a duplicate that has been used before or that you want to use 38:39.690 --> 38:42.930 before your friend actually uses it. 38:42.930 --> 38:48.550 So transferability, in principle, yes, because the money is not bound 38:48.550 --> 38:54.550 to a fixed hardware, but you cannot really decide whether the coin is 38:54.550 --> 38:58.170 still valid, so that's a tricky issue. 39:00.450 --> 39:06.990 Divisibility, you cannot divide the coin into smaller amounts, so just 39:06.990 --> 39:10.990 the coins that you send to the bank, exactly these coins you get back, 39:11.410 --> 39:13.190 and only these values you have available. 39:19.190 --> 39:27.410 So here's a list of banks that supported eCash, or DigiCash as it was 39:27.410 --> 39:36.910 called, but as I said, I'm not aware of any shops who actually use 39:36.910 --> 39:37.170 that. 39:38.470 --> 39:44.190 By the way, there would be also a nice system to get ransom, so 39:44.190 --> 39:51.430 Lösegeld, if you keep someone hostage and you say, I want to have some 39:51.430 --> 39:53.730 money to let this person go free. 39:53.730 --> 39:59.650 What you could do, if this would be implemented, this eCash, you could 39:59.650 --> 40:12.810 send the police a couple of blinded serial numbers and ask some bank 40:12.810 --> 40:20.830 to sign it blindly, put a blind signature on it, and then publish the 40:20.830 --> 40:22.510 result in a newspaper. 40:22.510 --> 40:27.710 And anyone could read this newspaper, but only the person who knows 40:27.710 --> 40:31.630 the blinding factor could turn this into real money and it would be 40:31.630 --> 40:33.790 completely anonymous and would not be traceable. 40:35.810 --> 40:41.090 And another problem of course would be that this system might allow 40:41.090 --> 40:45.630 large amounts of money to be transferred in an anonymous way. 40:49.410 --> 40:53.470 But at least for small amounts of money, I think it would be a 40:53.470 --> 40:54.250 suitable system. 40:57.570 --> 41:02.710 Another possibility for electronic money is of course smart cards. 41:07.650 --> 41:13.270 I'm sure most of you have this Geldkarte, you can use these smart 41:13.270 --> 41:17.170 cards to pay for tram tickets, to pay for stamps. 41:18.190 --> 41:21.690 It's generally used for small amounts of money. 41:23.670 --> 41:29.570 It has an offline capability which makes it a lot cheaper and 41:29.570 --> 41:35.070 therefore that's also the reason, I guess, why it's used for small 41:35.070 --> 41:35.830 amounts of money. 41:37.330 --> 41:43.950 Generally it's prepaid cards, so you pay the bank, or the bank 41:43.950 --> 41:47.530 subtracts the money from your bank account and then transfers it 41:47.530 --> 41:50.950 electronically to your smart card. 41:53.390 --> 41:56.730 The problem is that with smart cards you need these readers. 41:57.370 --> 42:01.030 Only very few of you, I guess, have these at home. 42:01.690 --> 42:05.430 In principle you can have a reader at home and use it also for payment 42:05.430 --> 42:10.810 over the internet, but mostly it's used in shops or you like to buy 42:10.810 --> 42:12.210 cigarettes and things like that. 42:15.830 --> 42:20.030 Okay, I'm not going to talk about the technical details. 42:21.510 --> 42:28.510 The advantages over standard bank cards are improved security, because 42:28.510 --> 42:33.670 you not only have this magnetic stripe that can be easily forged, you 42:33.670 --> 42:34.870 have a larger memory. 42:36.670 --> 42:41.630 Some cards allow mutual authentication of the card and the terminal. 42:43.130 --> 42:47.930 So the card is generally always authenticated, but it allows also 42:47.930 --> 42:50.970 authentication of the terminal. 42:51.230 --> 42:54.390 And if the terminal doesn't respond in the right way, the card can 42:54.390 --> 42:57.290 just say, I'm not giving you the information. 42:59.650 --> 43:07.170 There are additional things you have to consider if you have these 43:07.170 --> 43:07.950 smart cards. 43:08.630 --> 43:15.690 The early smart cards had severe attacks by looking at the power 43:15.690 --> 43:17.890 consumption, for example, of the card. 43:18.370 --> 43:22.690 From that you could calculate what keys it is using, what algorithms 43:22.690 --> 43:23.830 it is using, etc. 43:23.830 --> 43:32.850 Looking at the time it needs to respond, or even the possibility to 43:32.850 --> 43:39.110 make some physical damages to the card and see how this would affect 43:39.110 --> 43:41.250 the card's operability. 43:42.490 --> 43:45.530 And so you have to take this into account if you build smart cards, 43:46.150 --> 43:49.230 you have to think about all these physical attacks also. 43:52.350 --> 43:56.350 If you have a reader at home, you can use it for transactions under 43:56.350 --> 44:01.950 this Home Banking Interface standard, which is now called FINTS, I 44:01.950 --> 44:06.770 think, Financial Transaction Service or something like that. 44:09.370 --> 44:13.670 And there's also a product from this fun company that I already 44:13.670 --> 44:16.750 mentioned, which is located here in Karlsruhe, that allows you to pay 44:16.750 --> 44:19.370 with your smart cards over the Internet. 44:22.530 --> 44:28.470 There are certain standards on what such smart cards should be able to 44:28.470 --> 44:28.930 do. 44:31.770 --> 44:37.110 Of course, you should be able to load money on this card and to 44:37.110 --> 44:41.600 purchase something with this card, but there are more requirements. 44:41.600 --> 44:44.080 One is incremental purchase. 44:44.700 --> 44:50.000 So if you want to use this card, for example, in a telephone, you want 44:50.000 --> 44:57.000 to be able to insert it once and then incrementally deduct money from 44:57.000 --> 45:02.880 that card without having the complex authentication and so on, always 45:02.880 --> 45:05.580 for every little bit of money that you want to deduct. 45:05.580 --> 45:11.540 But once the card is inserted and authenticated, you should be able to 45:11.540 --> 45:14.060 incrementally deduct money. 45:15.480 --> 45:22.700 You want to be able to reverse a purchase and cancel. 45:23.260 --> 45:26.800 And the difference between reversal and cancel in this specification 45:26.800 --> 45:31.340 is that reversal is while the card is still in the machine, you want 45:31.340 --> 45:37.060 to be able to reverse it and cancel is you took the card out and then 45:37.060 --> 45:40.380 you realize, oh, something went wrong or I want to give the product 45:40.380 --> 45:42.960 back and you want to be able to put the money back on. 45:42.960 --> 45:48.460 To put it back in the machine and cancel the last purchase. 45:50.000 --> 45:55.420 And then you have the problem that if you want to use that card in 45:55.420 --> 45:59.700 different countries with different currencies, you somehow have to 45:59.700 --> 46:03.160 ensure that they subtract the right amount of currency. 46:04.560 --> 46:05.180 OK, 46:12.030 --> 46:15.030 yet another payment system would be Paybox. 46:15.430 --> 46:20.630 That works with your mobile phone as an authenticator, basically. 46:22.990 --> 46:24.210 Again, it's prepaid. 46:24.330 --> 46:26.030 The customer has to pay a certain amount. 46:26.230 --> 46:35.860 It's on Paybox... no, it doesn't seem to be prepaid. 46:38.060 --> 46:42.580 Anyway, so the customer pays basically with his or her mobile phone 46:42.580 --> 46:52.580 number and the merchant forwards this number to the Paybox clearing 46:52.580 --> 46:53.140 service. 46:53.740 --> 46:58.060 That clearing service calls the customer on the mobile phone, making 46:58.060 --> 47:02.580 thereby sure that it's really the customer who is requesting that 47:02.580 --> 47:02.960 payment. 47:04.420 --> 47:13.040 The customer authorizes the payment by entering a PIN and the clearing 47:13.040 --> 47:15.740 service then deducts the payment from the customer's account. 47:16.620 --> 47:18.180 It's not anonymous. 47:18.420 --> 47:25.960 It's just another way to ensure authenticity of the user. 47:26.960 --> 47:34.780 And of course, we know that all the mobile phones use encryption and 47:34.780 --> 47:35.280 authentication. 47:40.400 --> 47:43.100 You can have different security levels. 47:43.280 --> 47:51.240 Basically, if you have a software-only system, there's a much higher 47:51.240 --> 47:57.200 chance of fraud than if you have a smart card-based system where some 47:57.200 --> 48:02.840 part of the computation is fixed on that smart card and cannot be 48:02.840 --> 48:07.820 modified by viruses or whatever, or intruders. 48:11.580 --> 48:17.820 And then, in the best case, ultimate case, of course, you not only 48:17.820 --> 48:21.640 have the smart card, but you have a whole device that is separate from 48:21.640 --> 48:26.420 your computer and that is responsible for all the protocols and doing 48:26.420 --> 48:29.240 the transaction and entering the PIN number, etc. 48:34.030 --> 48:38.470 So, there are a couple of different online payment systems. 48:40.290 --> 48:54.040 Someone had the question earlier about offline payment systems that 48:54.040 --> 48:55.040 are untraceable. 48:55.940 --> 49:00.420 Well, that not necessarily means open loop, but still that would be 49:00.420 --> 49:04.300 the most advanced on this table. 49:04.880 --> 49:06.380 Maybe you can search for CAFE. 49:06.520 --> 49:08.040 I don't know whether it still exists. 49:08.620 --> 49:09.620 I don't know. 49:09.620 --> 49:14.080 So, we have looked here, for example, at eCash, which is untraceable, 49:14.180 --> 49:15.040 but it's online. 49:16.460 --> 49:23.480 We have looked at SSL, of course, SET as traceable online payment 49:23.480 --> 49:24.120 systems. 49:25.800 --> 49:30.900 So, there are a couple of different possibilities and you just have to 49:30.900 --> 49:33.340 pick one that fits your needs. 49:36.680 --> 49:40.460 Alright, any questions about electronic money? 49:45.990 --> 49:52.910 If not, we will move to the next chapter, 49:58.040 --> 50:01.540 which is firewalls. 50:16.440 --> 50:29.200 So, firewalls are there to protect your personal computer or your 50:29.200 --> 50:35.600 private network against external attacks and also at the same time 50:35.600 --> 50:39.540 they can be used to control the internet access by local users. 50:39.540 --> 50:44.900 So, you might not want your employees to use the internet freely 50:44.900 --> 50:46.060 during your work time. 50:47.260 --> 50:52.480 Firewall can filter the traffic that goes in and out of your network 50:52.480 --> 50:58.380 and thereby protect this internal private network. 51:00.620 --> 51:05.240 So, without a firewall, every node on the internet can, in principle, 51:06.660 --> 51:10.880 attack and communicate with every node on the private network. 51:11.280 --> 51:17.140 If you have this firewall, then the nodes on the internet can only 51:17.140 --> 51:21.320 attack the firewall because only that firewall is really connected and 51:21.320 --> 51:23.520 allowed to communicate with the outside world. 51:23.520 --> 51:32.800 And on the private network, the private network always has to go 51:32.800 --> 51:33.900 through this firewall. 51:34.540 --> 51:37.560 And if you make this firewall secure, it's much easier to 51:37.560 --> 51:41.480 administrate, of course, if you have a company network. 51:41.480 --> 51:48.780 You don't have to make every single computer secure, which is very 51:48.780 --> 51:50.200 hard to do. 51:50.640 --> 51:54.820 It's sufficient if you have... well, at least it's one big step if you 51:54.820 --> 51:55.900 have a secure firewall. 51:58.100 --> 52:03.420 On the other hand, of course, because everything goes through that 52:03.420 --> 52:08.040 firewall and because you can trace everything there, you can also 52:08.040 --> 52:16.340 implement some big brother structure so you can block access to the 52:16.340 --> 52:21.640 internet from the private network and also lock all the data that 52:21.640 --> 52:22.140 the... 52:22.140 --> 52:25.340 all the websites that the users access, for example. 52:28.000 --> 52:30.280 What are you trying to protect? 52:31.300 --> 52:34.040 Of course, you are trying to protect your data. 52:34.420 --> 52:38.540 You have confidential data that you don't want anyone else to have. 52:39.180 --> 52:43.640 You want to make sure that your data... you want to ensure your data 52:43.640 --> 52:48.740 integrity so that no one is able to modify your data and thereby maybe 52:48.740 --> 52:53.620 influence your decisions because you base your decisions on the data 52:53.620 --> 52:54.220 in your database. 52:54.220 --> 52:58.960 And if that data has been modified, you can be tricked into doing some 52:58.960 --> 53:00.700 wrong decisions. 53:02.080 --> 53:07.380 And, of course, you want to avoid that your data becomes destroyed. 53:08.940 --> 53:11.560 You also want to protect your resources. 53:12.620 --> 53:17.880 You have computational power that you want to be able to use. 53:18.340 --> 53:22.720 You want to use it internally or you want to provide it as a service 53:22.720 --> 53:25.040 to the external community. 53:25.400 --> 53:31.020 If you have a web server, you provide computational resources for 53:31.020 --> 53:31.940 others to access. 53:32.580 --> 53:39.300 And you want to protect that, of course, that is not used by anyone 53:39.300 --> 53:42.660 else for, for example, sending spam. 53:43.040 --> 53:46.600 You want to protect... that's the next keyword... you want to protect 53:46.600 --> 53:47.440 your reputation. 53:47.440 --> 53:53.680 If someone is using your computers to do some nasty things, for 53:53.680 --> 53:59.580 example, like sending out millions of spam messages, then the result 53:59.580 --> 54:06.040 may be that you get blacklisted and you can't send any emails, also 54:06.040 --> 54:11.020 regular emails, anymore because others have recognized that you are 54:11.020 --> 54:12.060 sending a lot of spam. 54:12.060 --> 54:16.140 And so they just block all the email traffic from your servers. 54:16.860 --> 54:21.320 And so you want to protect your reputation in that sense. 54:24.260 --> 54:28.700 Possible attacks from the internet are intrusion, of course, 54:29.000 --> 54:29.420 someone... 54:29.420 --> 54:34.840 that's maybe the worst case, someone logging into your computer and 54:34.840 --> 54:37.980 then doing nasty things there. 54:39.120 --> 54:46.280 Denial of service attacks are maybe the most difficult to prevent. 54:46.900 --> 54:52.060 Denial of service means that you are basically flooded with requests 54:52.060 --> 54:54.720 of different sorts. 54:55.420 --> 54:59.560 It can be logging requests, it can be web page requests, it can be 54:59.560 --> 55:01.320 communication requests, whatever. 55:01.320 --> 55:08.100 So you have a couple of servers that are connected to the internet, or 55:08.100 --> 55:16.080 even your personal computer, if you swamp them with requests, then the 55:16.080 --> 55:20.700 computer will not be able to handle that workload, and it will 55:20.700 --> 55:25.560 basically slow down so much that you can't use it anymore. 55:25.560 --> 55:32.920 And that means basically your service becomes unavailable, and of 55:32.920 --> 55:38.980 course that's very hard to counteract, because you would have to check 55:38.980 --> 55:43.500 which of these requests are valid and which are not, and that alone, I 55:43.500 --> 55:49.480 mean, requires so much computational resources that it will slow down 55:49.480 --> 55:52.780 and will have exactly the denial of service effect. 55:54.080 --> 55:59.360 You want to prevent theft of information, and also modification of 55:59.360 --> 55:59.960 information. 56:05.710 --> 56:12.110 You can have... if you want to have a higher security, there are two 56:12.110 --> 56:13.370 things that you can address. 56:13.910 --> 56:20.570 One is you can make the individual computers more secure, and the 56:20.570 --> 56:24.490 other thing is that you make your network more secure by putting a 56:24.490 --> 56:28.350 firewall between your private network and the public network. 56:28.350 --> 56:33.830 The problem with host security, so making the individual computers 56:33.830 --> 56:39.130 more secure, is that you have a diverse environment, many different 56:39.130 --> 56:44.190 users that have different needs, that need different programs, that 56:44.190 --> 56:51.070 have access to their computer, that can modify the firewall settings 56:51.070 --> 56:54.890 on their computer, because they want to install something, or because 56:54.890 --> 56:56.990 they want to have free access to the internet. 56:58.350 --> 57:02.670 Very difficult to administrate, you have to go through all these 57:02.670 --> 57:11.090 computers, maybe install some special software, lots of work, but on 57:11.090 --> 57:14.170 the other hand, it's maybe the only efficient way for virus 57:14.170 --> 57:19.790 protection, because virus protection is a very computationally 57:19.790 --> 57:22.450 demanding application. 57:23.030 --> 57:27.770 You basically have to look into the document that you exchange with 57:27.770 --> 57:31.810 the outside world, and if you would want to do that at a central place 57:31.810 --> 57:35.310 for the whole network, it would just be computationally too expensive. 57:37.510 --> 57:41.510 And you also need the applications for it, etc. 57:41.690 --> 57:41.870 etc. 57:42.570 --> 57:46.530 So for virus protection, maybe it's the only practicable way. 57:49.290 --> 57:54.530 If you have this firewall that protects your whole network, you have 57:54.530 --> 57:57.990 this bottleneck problem, because everything has to go through that 57:57.990 --> 58:04.970 firewall, and you have to scan all the data, which makes, in 58:04.970 --> 58:07.570 particular, application screening very difficult. 58:10.550 --> 58:16.530 Also difficult, because you need to have filters for every different 58:16.530 --> 58:22.910 application, and if you don't know what the users are using, that's an 58:22.910 --> 58:23.750 additional difficulty. 58:24.050 --> 58:28.650 So one reason is that you have so many different applications, the 58:28.650 --> 58:31.170 other reason is that it's computationally very demanding. 58:34.570 --> 58:40.250 Network security also provides no protection against, of course, 58:40.410 --> 58:42.430 mobile devices like memory sticks. 58:42.850 --> 58:48.930 If you allow your computers to have USB ports, people will plug in 58:48.930 --> 58:52.050 memory sticks, they will plug in an iPod or whatever. 58:52.050 --> 58:58.990 And, of course, a firewall that separates the public network from your 58:58.990 --> 59:03.170 private network cannot protect against such devices. 59:03.670 --> 59:09.710 Host security could, virus protection there could, this could not. 59:10.490 --> 59:14.990 But the big benefit, of course, is that it's much better to control 59:14.990 --> 59:16.810 and administrate. 59:17.610 --> 59:20.430 So the conclusion is that basically you need both. 59:21.170 --> 59:23.090 Both have some advantages. 59:24.150 --> 59:31.190 You need the network security as a first level threshold and 59:31.190 --> 59:35.230 protection, and then you need host security as a second level. 59:41.360 --> 59:47.100 Firewalls can prevent unauthorized access, they can log the traffic, 59:48.140 --> 59:54.660 they can then analyze the traffic pattern, and if they detect some 59:54.660 --> 01:00:02.340 suspicious activities, maybe they can alarm the administrator or shut 01:00:02.340 --> 01:00:03.180 down the firewall. 01:00:04.180 --> 01:00:09.060 But the question is, what is suspicious? 01:00:10.180 --> 01:00:11.600 And that's the hard question. 01:00:13.700 --> 01:00:23.020 I think this is an ongoing research issue to detect suspicious 01:00:23.020 --> 01:00:23.560 activities. 01:00:23.560 --> 01:00:29.740 There are people thinking about adopting ideas from immune systems, 01:00:30.220 --> 01:00:38.400 from the human immune system, or in mammals, and transfer this idea to 01:00:38.400 --> 01:00:45.920 artificial immune system that learns what messages are typical, and 01:00:45.920 --> 01:00:50.140 then if something new comes up, something strange comes up, it will 01:00:50.140 --> 01:00:52.680 alarm the administrator and detect that. 01:00:53.560 --> 01:00:58.760 But still, of course, it's a difficult issue, and the attackers at the 01:00:58.760 --> 01:01:04.840 other end always compete with the system administrators that try to 01:01:04.840 --> 01:01:08.840 protect the system, and they will come up, of course, again with 01:01:08.840 --> 01:01:17.300 attacks that exactly avoid that, and they look just harmless, and only 01:01:17.300 --> 01:01:19.040 show their potential if it's too late. 01:01:22.100 --> 01:01:28.400 Firewalls may serve as a proxy to the Internet, which means that they 01:01:28.400 --> 01:01:41.780 can cache data and maybe lead to a faster response if several people 01:01:41.780 --> 01:01:47.540 in your network try to access the same websites very often, and that's 01:01:47.540 --> 01:01:48.500 usually the case. 01:01:48.500 --> 01:01:56.000 You have usually an exponential distribution, you have very few 01:01:56.000 --> 01:01:59.800 websites that are accessed by many people very often, and you have 01:01:59.800 --> 01:02:04.640 many, many, many websites that are accessed basically never. 01:02:04.640 --> 01:02:11.140 So you can store these very popular websites on your proxy server, 01:02:12.120 --> 01:02:16.640 that usually is also a firewall, and then if many people request the 01:02:16.640 --> 01:02:22.740 document, just serve it from the cache, and not always ask for a new 01:02:22.740 --> 01:02:24.120 copy of the same document. 01:02:26.500 --> 01:02:28.300 Limited virus protection. 01:02:29.080 --> 01:02:32.880 Limited, as I said before, because it's very time-consuming and 01:02:32.880 --> 01:02:35.460 difficult to do that on the firewall level. 01:02:38.540 --> 01:02:44.160 You can restrict the services available to internal users, you can 01:02:44.160 --> 01:02:47.600 also separate parts of the internal network, as we will see. 01:02:47.600 --> 01:02:54.220 You don't necessarily have to only have the public network and the 01:02:54.220 --> 01:02:59.420 internal, but you may have some intermediate network that is maybe 01:02:59.420 --> 01:03:04.760 used for your web servers, so they are internal, but still they are 01:03:04.760 --> 01:03:12.360 protected from the real internal network, and they may provide 01:03:12.360 --> 01:03:14.180 services to the outside world. 01:03:18.450 --> 01:03:22.510 What firewalls can't do, of course, is protection against malicious 01:03:22.510 --> 01:03:29.410 insiders, and I would guess that most of the attacks, of the harmful 01:03:29.410 --> 01:03:32.470 attacks, are by insiders, and not from the outside. 01:03:32.470 --> 01:03:35.130 And that's where firewalls can't help. 01:03:37.510 --> 01:03:42.870 I already mentioned that they can't protect against data flow around 01:03:42.870 --> 01:03:48.530 it, with memory sticks or iPods or modems or whatever, and only 01:03:48.530 --> 01:03:50.350 limited protection against viruses. 01:03:50.610 --> 01:03:50.810 Why? 01:03:50.810 --> 01:03:57.670 I already mentioned that it's too time-consuming to really look at the 01:03:57.670 --> 01:03:58.310 application. 01:03:59.170 --> 01:04:05.930 Other reasons... so I may actually add this here... 01:04:10.460 --> 01:04:19.500 so it's just computationally too expensive to do that checking. 01:04:20.500 --> 01:04:24.960 That maybe corresponds to the second reason here, only packets of data 01:04:24.960 --> 01:04:30.100 are seen, because it would be computationally so expensive to look 01:04:30.100 --> 01:04:38.300 into every data packet and reconstruct the messages from the packets. 01:04:38.300 --> 01:04:43.940 What most of these firewalls do is that they just do packet filtering, 01:04:44.140 --> 01:04:48.280 so just at the IP or TCP level, so they don't go at the application 01:04:48.280 --> 01:04:55.640 layer, and therefore it's very hard to identify viruses. 01:04:56.960 --> 01:05:01.880 Another reason may be that a lot of the data that you send through the 01:05:01.880 --> 01:05:07.220 internet is compressed, so you would have to, before you can detect a 01:05:07.220 --> 01:05:11.560 virus, you would have to uncompress the data, again, computationally 01:05:11.560 --> 01:05:17.840 too expensive, so that what some networks or firewalls do is they just 01:05:17.840 --> 01:05:20.580 don't allow you to send compressed data. 01:05:24.900 --> 01:05:29.280 And of course you have the problem that the machines in your network 01:05:29.280 --> 01:05:32.580 may consist of different operating systems, you may have Linux 01:05:32.580 --> 01:05:39.360 machines, you may have PCs, so Microsoft and Macintosh, and different 01:05:39.360 --> 01:05:44.600 viruses attack different machines, but at the firewall you would have 01:05:44.600 --> 01:05:47.520 to be able to detect all these different viruses for the different 01:05:47.520 --> 01:05:47.940 machines. 01:05:53.960 --> 01:05:59.980 If you set up a firewall, you should think about, really, what's your 01:05:59.980 --> 01:06:06.200 security policy, what services do you need, what are the groups of 01:06:06.200 --> 01:06:11.100 people that need particular services, do you have to make these 01:06:11.100 --> 01:06:15.800 services available to everyone, can you maybe separate your network 01:06:15.800 --> 01:06:21.040 into different parts with different security levels, because maybe 01:06:21.040 --> 01:06:27.400 your research department needs more access than your production 01:06:27.400 --> 01:06:30.120 department or secretary or whatever. 01:06:32.920 --> 01:06:39.820 So for each service group, how should it be kept or made secure, and 01:06:39.820 --> 01:06:47.520 of course, you then have to... you can have two things, you can say 01:06:47.520 --> 01:06:51.520 this is a positive list, all these transactions, all these messages 01:06:51.520 --> 01:06:57.720 are allowed, and everything else is denied, which is much stronger 01:06:57.720 --> 01:06:58.700 than saying, 01:07:12.660 --> 01:07:19.650 There are different firewall architectures, and I'm going to discuss 01:07:19.650 --> 01:07:21.950 them in turn. 01:07:21.950 --> 01:07:27.270 The simplest one is packet filtering. 01:07:27.910 --> 01:07:33.790 Then we will look at dual home host, screen host architecture, and 01:07:33.790 --> 01:07:35.070 screen subnet architecture. 01:07:35.610 --> 01:07:41.810 That's different ways how you set your firewalls in different places. 01:07:46.390 --> 01:07:51.530 So packet filtering is generally on the IP level. 01:07:53.050 --> 01:07:59.290 Partially they look into information on the TCP level, but they 01:07:59.290 --> 01:08:04.930 basically just peek into the TCP header and extract the port 01:08:04.930 --> 01:08:09.910 information, which specifies or which gives you an idea of what 01:08:09.910 --> 01:08:13.430 application is using or sending these packets. 01:08:13.430 --> 01:08:21.150 But that goes very quickly, because every router has to read the 01:08:21.150 --> 01:08:23.890 information in the IP header anyway. 01:08:24.950 --> 01:08:28.450 So it can be performed by a single router, it just has to go through 01:08:28.450 --> 01:08:35.910 usually a list of rules that specify whether these particular packets 01:08:35.910 --> 01:08:39.150 are allowed through or should be discarded. 01:08:39.750 --> 01:08:40.270 So 01:08:50.180 --> 01:08:54.940 what information is available on the IP level? 01:08:56.320 --> 01:09:05.200 Of course the address that data is coming from, at least supposedly 01:09:05.200 --> 01:09:10.380 coming from, there is something called address spoofing. 01:09:10.380 --> 01:09:18.400 Spoofing is that you modify the packets and the from address, the 01:09:18.400 --> 01:09:24.440 source address, claiming that the packet comes from somewhere else. 01:09:26.260 --> 01:09:35.360 That's particularly often used in denial of service attacks, because 01:09:35.360 --> 01:09:40.520 there you are basically only interested in flooding the computer with 01:09:40.520 --> 01:09:44.580 requests, and you are not interested in getting any information back. 01:09:44.580 --> 01:09:51.760 Obviously if you use address spoofing, the application on the 01:09:51.760 --> 01:09:58.620 receiving side will think, okay, the wrong address is the address that 01:09:58.620 --> 01:10:01.920 I want to communicate with, and will send the response to that wrong 01:10:01.920 --> 01:10:06.600 address, so you cannot establish a real communication there. 01:10:07.360 --> 01:10:13.960 But if you do denial of service attacks, that doesn't bother you. 01:10:14.440 --> 01:10:21.600 On the contrary, if you use a wrong address, that server under attack 01:10:21.600 --> 01:10:27.240 will then try to send responses to that other server that you claim to 01:10:27.240 --> 01:10:32.640 be, and thereby you can indirectly attack yet another server, because 01:10:32.640 --> 01:10:37.880 then this other server will get a lot of traffic from the attack 01:10:37.880 --> 01:10:38.300 server. 01:10:41.120 --> 01:10:51.960 But in general, you know the source address, and if there is an 01:10:51.960 --> 01:10:54.380 ongoing communication you can also trust it. 01:10:56.420 --> 01:10:59.280 Of course you know the address the data is going to. 01:11:01.560 --> 01:11:07.800 So if it's an incoming message, you know what computer it is going to 01:11:07.800 --> 01:11:11.680 in your internal network, and you know what computer it's going to in 01:11:11.680 --> 01:11:15.780 the outside network, if it's an outgoing message. 01:11:20.220 --> 01:11:25.700 You have some information on the session and application protocols, so 01:11:25.700 --> 01:11:29.540 are you using TCP, are you using UDP, things like that. 01:11:29.540 --> 01:11:34.680 And of course the easiest way would be to block certain IP addresses, 01:11:35.120 --> 01:11:40.860 if you have certain blacklists, if you have had attacks from certain 01:11:40.860 --> 01:11:44.880 IP addresses before, you may just not accept any packets from these IP 01:11:44.880 --> 01:11:45.340 addresses. 01:11:46.100 --> 01:11:51.080 You may block certain services like FTP, SSH, etc. 01:11:52.240 --> 01:11:54.140 by blocking certain ports. 01:11:55.300 --> 01:11:59.440 As I said, the port information is only available on the TCP level, 01:12:00.700 --> 01:12:06.240 but you can sort of peek into the TCP header and look at the port of 01:12:06.240 --> 01:12:08.320 these packets. 01:12:11.240 --> 01:12:20.280 You can restrict TCP connections to connections that are initiated 01:12:20.280 --> 01:12:21.480 from the inside. 01:12:25.060 --> 01:12:31.060 You can see that from the acknowledgement bit, that in the first 01:12:31.060 --> 01:12:42.280 message, the initial message is zero, because there is no 01:12:42.280 --> 01:12:45.700 acknowledgement in there, and from then on the acknowledgement bit is 01:12:45.700 --> 01:12:46.880 always one. 01:12:46.880 --> 01:12:54.360 So you can not accept messages with an acknowledgement bit set to zero 01:12:54.360 --> 01:12:55.300 from the outside. 01:12:58.000 --> 01:13:03.060 And you can do something more advanced, which is called dynamic packet 01:13:03.060 --> 01:13:08.440 filtering, where you monitor the state of the connections, and you not 01:13:08.440 --> 01:13:11.900 only look at individual packets, but you say, okay, I know that these 01:13:11.900 --> 01:13:14.420 two computers have established a connection. 01:13:14.420 --> 01:13:23.880 You trace the handshake between these computers, and how the 01:13:23.880 --> 01:13:28.960 connection is built up, and then you accept this particular connection 01:13:28.960 --> 01:13:33.840 and messages or packets between these computers, and you also trace 01:13:33.840 --> 01:13:38.140 when they close the connection, and from then on you don't accept any 01:13:38.140 --> 01:13:40.920 more packets from that connection. 01:13:41.740 --> 01:13:46.700 So there you basically go to the TCP layer. 01:13:48.840 --> 01:13:52.400 Information that is never available is information about the users, 01:13:52.780 --> 01:13:57.480 and the content of the files, if you just do packet filtering. 01:13:59.060 --> 01:14:02.300 So that's also, I mean, virus protection is not possible on that 01:14:02.300 --> 01:14:02.580 level. 01:14:05.840 --> 01:14:08.340 There are a couple of problems with packet filtering. 01:14:08.560 --> 01:14:11.060 One is that the IP packets may be fragmented. 01:14:11.600 --> 01:14:15.520 Remember from the beginning of this course that we talked about 01:14:15.520 --> 01:14:19.420 fragments on the IP level. 01:14:20.600 --> 01:14:25.900 That means that the header of the higher level protocols, like also 01:14:25.900 --> 01:14:30.460 TCP header, is only available in the first fragment. 01:14:31.740 --> 01:14:45.040 So TCP has a certain data package, and so the TCP header is only in 01:14:45.040 --> 01:14:52.560 front of that, and if IP separates that into several fragments, then 01:14:52.560 --> 01:14:55.380 the TCP header is only in the first fragment. 01:14:55.380 --> 01:15:09.200 And that could lead that only the first fragment of such a datagram is 01:15:09.200 --> 01:15:13.540 filtered, because only there you can look at the port number, and the 01:15:13.540 --> 01:15:14.320 others get through. 01:15:16.040 --> 01:15:21.440 Also, this is often used in denial-of-service attacks, because then 01:15:21.440 --> 01:15:25.820 the receiver waits for the first packet and will never get it. 01:15:33.790 --> 01:15:38.830 I already talked about address spoofing, that you claim you are 01:15:38.830 --> 01:15:48.250 someone else, which may lead to denial-of-service attacks if the 01:15:48.250 --> 01:15:52.290 source address is invalid, because then the server will try to 01:15:52.290 --> 01:15:54.430 communicate with someone who doesn't exist. 01:15:54.430 --> 01:16:00.730 And it may lead to the blocking of innocent addresses if the source 01:16:00.730 --> 01:16:06.170 address is incorrect for once, because you will try to communicate 01:16:06.170 --> 01:16:12.530 with that incorrect source, and you will affect that source, and the 01:16:12.530 --> 01:16:18.150 administrator at this source may then blacklist you and not accept any 01:16:18.150 --> 01:16:19.610 more packages from you. 01:16:19.610 --> 01:16:24.690 So, address spoofing is an issue here. 01:16:27.610 --> 01:16:31.330 I said that packet filtering is done mostly on the IP level. 01:16:32.130 --> 01:16:37.550 The question is, can you go even lower, maybe on the physical layer, 01:16:38.010 --> 01:16:42.350 but that is not reasonable, because most packets from the outside come 01:16:42.350 --> 01:16:44.390 through the same hardware router. 01:16:45.250 --> 01:16:49.230 So, on the physical layer you could only see from what other router is 01:16:49.230 --> 01:16:52.670 it coming, but most of your traffic goes through the same router, so 01:16:52.670 --> 01:16:56.530 this is not really useful. 01:17:09.110 --> 01:17:09.690 So, 01:17:13.790 --> 01:17:17.430 the screening routers means exactly that picture that we saw before, 01:17:17.570 --> 01:17:22.450 here we have the internet, and then we have here this screening 01:17:22.450 --> 01:17:25.950 router, and this is your private network. 01:17:28.890 --> 01:17:37.570 That's the most simple kind of firewall, but then all you need is a 01:17:37.570 --> 01:17:41.270 router in between, but that means you have very little logging 01:17:41.270 --> 01:17:44.630 information, because it's only a router in between. 01:17:47.670 --> 01:17:52.150 It's difficult to set up screening rules, that depends. 01:17:54.330 --> 01:18:01.010 But one issue also is that the DNS addresses of all your computers in 01:18:01.010 --> 01:18:05.330 your private network have to be known to the outside. 01:18:12.560 --> 01:18:18.200 And one issue is that you can only do packet level filtering, but 01:18:18.200 --> 01:18:21.740 services may be tunneled on top of other services. 01:18:25.360 --> 01:18:28.480 So, I think I have an example. 01:18:32.820 --> 01:18:40.780 Tunneled means that you wrap basically the packets of a particular 01:18:40.780 --> 01:18:46.800 service within the packets or in the payload of the packets of another 01:18:46.800 --> 01:18:47.360 service. 01:18:47.900 --> 01:18:51.520 So, from the outside, from the packet filtering, it looks like one 01:18:51.520 --> 01:18:56.200 particular service, but if it's unwrapped in the inside, it turns out 01:18:56.200 --> 01:18:58.520 to be a different service. 01:18:59.100 --> 01:19:04.020 So, you may not be able to detect on the packet level such tunneled 01:19:04.020 --> 01:19:07.940 services, and of course you cannot add authentication. 01:19:09.920 --> 01:19:14.340 Here are some examples for rules for packet filtering. 01:19:16.680 --> 01:19:23.700 So, this rule A would say if the direction of the communication is in, 01:19:24.640 --> 01:19:28.980 the source address is external, the destination address is internal, 01:19:30.680 --> 01:19:37.340 protocol is TCP, source port is something greater than 1023, and 01:19:37.340 --> 01:19:44.760 destination port is 25, which is SMTP, so it's an email, the 01:19:44.760 --> 01:19:49.940 acknowledge bit said you allow anything, then you allow that message 01:19:49.940 --> 01:19:50.680 to get through. 01:19:51.680 --> 01:19:59.760 So, basically this set of rules would only allow ingoing and outgoing 01:19:59.760 --> 01:20:04.880 emails, and here this last rule would basically block everything else. 01:20:05.260 --> 01:20:11.060 So, only if you have source port or destination port being equal to 25 01:20:11.060 --> 01:20:17.380 SMTP, you would allow this packet to go through. 01:20:23.890 --> 01:20:28.070 Other possibilities for firewalls are these bastion hosts, where you 01:20:28.070 --> 01:20:30.770 actually put a computer, not only a router, in between. 01:20:33.230 --> 01:20:41.110 I'll show you some particular setups, but I think I have to finish 5 01:20:41.110 --> 01:20:44.870 minutes early today, because I have another lecture at the other end 01:20:44.870 --> 01:20:49.350 of the campus, right after this one, and it always takes me some time 01:20:49.350 --> 01:20:50.410 to put down the equipment. 01:20:50.410 --> 01:20:53.950 So let me stop here at this point and talk about the different 01:20:53.950 --> 01:21:00.190 configurations on how to set up these firewalls in the network next 01:21:00.190 --> 01:21:00.470 week. 01:21:01.290 --> 01:21:06.890 Next week we will finish this chapter, we will have some time for 01:21:06.890 --> 01:21:14.470 questions, exam questions, if you have any questions in advance, you 01:21:14.470 --> 01:21:15.750 can also send me an email. 01:21:16.450 --> 01:21:21.150 If you don't understand some parts of the course, we could go into 01:21:21.150 --> 01:21:22.630 details there. 01:21:23.010 --> 01:21:27.870 I will bring the assistant Andreas Kamper with me, so we will be there 01:21:27.870 --> 01:21:28.830 to answer questions. 01:21:29.330 --> 01:21:29.670 Thanks.