1 00:00:20,560 --> 00:00:22,795 We started last time on protection. 2 00:00:28,254 --> 00:00:30,170 You remember the model that we're considering? 3 00:00:30,170 --> 00:00:35,140 We've got some client communicating over the Internet 4 00:00:35,140 --> 00:00:37,450 with some server. 5 00:00:37,450 --> 00:00:40,710 And we said that there are three main technical problems 6 00:00:40,710 --> 00:00:42,210 that we're going to look to address. 7 00:00:42,210 --> 00:00:48,970 There is the problem of authentication, 8 00:00:48,970 --> 00:00:57,930 the problem of authorization and the problem of confidentiality. 9 00:01:05,689 --> 00:01:07,230 Today what we're going to do is we're 10 00:01:07,230 --> 00:01:09,940 going to talk mostly about this issue of authentication, 11 00:01:09,940 --> 00:01:12,684 but I want to just return to some of the details 12 00:01:12,684 --> 00:01:14,600 that we were talking about at the end of class 13 00:01:14,600 --> 00:01:18,960 last time so that you guys all get the important bits out 14 00:01:18,960 --> 00:01:22,540 of our discussion of the RSA protocol. 15 00:01:22,540 --> 00:01:24,630 Remember, last time we started talking 16 00:01:24,630 --> 00:01:30,370 about these are the main requirements of a protection 17 00:01:30,370 --> 00:01:32,000 system. 18 00:01:32,000 --> 00:01:35,950 And we drew a diagram that said that at the top level 19 00:01:35,950 --> 00:01:37,992 we want to have an application that is protected. 20 00:01:37,992 --> 00:01:39,449 Underneath that we're going to have 21 00:01:39,449 --> 00:01:40,820 a set of security primitives. 22 00:01:40,820 --> 00:01:42,450 And then, underlying all of this, 23 00:01:42,450 --> 00:01:43,870 we're going to have cryptography. 24 00:01:43,870 --> 00:01:46,400 Cryptography is going to be sort of the essential technique 25 00:01:46,400 --> 00:01:50,540 that we use to enable protection. 26 00:01:50,540 --> 00:01:56,700 We talked briefly about several different types 27 00:01:56,700 --> 00:01:58,370 of cryptography. 28 00:01:58,370 --> 00:02:00,130 Remember, we had our model where we 29 00:02:00,130 --> 00:02:05,260 have A is sending through some box which takes the data 30 00:02:05,260 --> 00:02:09,240 and transforms it using some cryptographic transform. 31 00:02:09,240 --> 00:02:12,390 And then that cryptographically transformed data gets 32 00:02:12,390 --> 00:02:18,350 transmitted and then is reverse transformed or untransformed 33 00:02:18,350 --> 00:02:23,550 at the other side and it comes out to the receiver. 34 00:02:23,550 --> 00:02:26,890 What cryptography does is we said 35 00:02:26,890 --> 00:02:30,980 that we want this open model where there is some key k1 here 36 00:02:30,980 --> 00:02:36,160 and some key k2 here that are used 37 00:02:36,160 --> 00:02:39,040 to decide how this transform operator works 38 00:02:39,040 --> 00:02:41,840 and this untransform operator works on the other side. 39 00:02:41,840 --> 00:02:49,890 We talked about a shared key case where k1 is equal to k2. 40 00:02:49,890 --> 00:02:52,930 And the appendix A of the chapter in the notes 41 00:02:52,930 --> 00:02:56,190 goes over a shared key protocol called DES 42 00:02:56,190 --> 00:02:59,090 that is fairly commonly used. 43 00:02:59,090 --> 00:03:01,590 The basic idea behind shared key cryptography 44 00:03:01,590 --> 00:03:04,340 is typically that both sides have this key 45 00:03:04,340 --> 00:03:11,030 and we're going to transform the data by combining the message 46 00:03:11,030 --> 00:03:14,039 stream that is coming from A together 47 00:03:14,039 --> 00:03:15,830 with the key in some way, say, for example, 48 00:03:15,830 --> 00:03:18,880 by xoring the data in many different ways 49 00:03:18,880 --> 00:03:23,240 or permuting the data around and then xoring it 50 00:03:23,240 --> 00:03:25,340 with the key in some combination of ways. 51 00:03:25,340 --> 00:03:27,159 That's sort of what the DES protocol does. 52 00:03:27,159 --> 00:03:28,700 It's just multiple rounds, basically, 53 00:03:28,700 --> 00:03:31,910 of permuting and xoring the data over and over again. 54 00:03:31,910 --> 00:03:35,610 The idea is that if an attacker doesn't know the key, 55 00:03:35,610 --> 00:03:37,850 it's very hard for them to reverse this process 56 00:03:37,850 --> 00:03:39,266 without having the key, but if you 57 00:03:39,266 --> 00:03:42,580 know the key it's relatively easy to reverse the process. 58 00:03:42,580 --> 00:03:48,200 We also talked a little bit about public key cryptography 59 00:03:48,200 --> 00:03:51,420 where k1 is not equal to k2. 60 00:03:55,230 --> 00:03:57,990 In this case, we started talking about this protocol 61 00:03:57,990 --> 00:04:01,635 RSA which is an example of a public key protocol. 62 00:04:06,590 --> 00:04:09,140 If you remember, RSA has some set 63 00:04:09,140 --> 00:04:13,514 of rules for actually doing the transformation of data. 64 00:04:13,514 --> 00:04:14,930 The basic idea is that we're going 65 00:04:14,930 --> 00:04:18,839 to get a private key and a public key 66 00:04:18,839 --> 00:04:21,320 here, which is going to consist of this prime number 67 00:04:21,320 --> 00:04:23,420 plus the product of these two prime numbers 68 00:04:23,420 --> 00:04:25,530 and this private key k which is going to consist 69 00:04:25,530 --> 00:04:27,310 of the other prime number and the product of these two 70 00:04:27,310 --> 00:04:28,140 things. 71 00:04:28,140 --> 00:04:31,060 Now we have this way in which we can transform the data. 72 00:04:31,060 --> 00:04:33,700 What this transform box does is simply raise the message 73 00:04:33,700 --> 00:04:38,400 to the power of e modulo n and we have the reverse transform. 74 00:04:38,400 --> 00:04:41,510 This is just a specific mathematical operation. 75 00:04:41,510 --> 00:04:43,980 The reason that this mathematical operation works 76 00:04:43,980 --> 00:04:48,300 is that the intuition is that it is relatively easy to take 77 00:04:48,300 --> 00:04:49,800 something to an exponent. 78 00:04:49,800 --> 00:04:51,550 I can take a number and exponentiate it 79 00:04:51,550 --> 00:04:53,060 without doing very much work. 80 00:04:53,060 --> 00:04:56,670 But in order for an attacker to compromise this system, that 81 00:04:56,670 --> 00:04:58,520 is in order to discover, for example, 82 00:04:58,520 --> 00:05:07,300 what the private key is, in this case, what this value d is, 83 00:05:07,300 --> 00:05:09,840 given just the public key which consists of e and n, 84 00:05:09,840 --> 00:05:18,510 the attacker is going to be able to factor this number n, which 85 00:05:18,510 --> 00:05:21,272 turns out to be very difficult to do. 86 00:05:21,272 --> 00:05:23,230 Essentially, breaking this cryptographic system 87 00:05:23,230 --> 00:05:25,590 comes down to be able to factor a very large number. 88 00:05:25,590 --> 00:05:27,590 And that turns out to be, computationally, very, 89 00:05:27,590 --> 00:05:28,465 very difficult to do. 90 00:05:28,465 --> 00:05:30,673 So that's sort of the intuition behind the protection 91 00:05:30,673 --> 00:05:31,310 of this scheme. 92 00:05:31,310 --> 00:05:33,630 The nice thing about RSA is it has, 93 00:05:33,630 --> 00:05:37,350 in most public key cryptographic protocols 94 00:05:37,350 --> 00:05:40,230 is that they have this property that the reverse is also true. 95 00:05:40,230 --> 00:05:45,620 So I can transform using exponentiation 96 00:05:45,620 --> 00:05:48,120 with the public key or the private key 97 00:05:48,120 --> 00:05:52,452 and I can reverse transform using the opposite. 98 00:05:52,452 --> 00:05:53,910 If I transform with the public key, 99 00:05:53,910 --> 00:05:56,564 I can reverse transform with the private key and vise versa. 100 00:05:56,564 --> 00:05:58,480 So we are going to exploit this property a lot 101 00:05:58,480 --> 00:06:03,590 when we're talking about this kind of cryptography. 102 00:06:03,590 --> 00:06:05,550 Just to sort of point out that this is hard, 103 00:06:05,550 --> 00:06:08,390 this is an estimate from the RSA Security Company 104 00:06:08,390 --> 00:06:12,320 about how many compute years on modern computers 105 00:06:12,320 --> 00:06:16,210 it would take to factor an RSA key of a given link. 106 00:06:16,210 --> 00:06:19,240 So the bottom is the key link in bytes on the x-axis 107 00:06:19,240 --> 00:06:24,060 and then the y-axis is the machine years to factor. 108 00:06:24,060 --> 00:06:26,740 If the machine years to factor was 1,000, 109 00:06:26,740 --> 00:06:29,430 that means it would take 1,000 machines working together 110 00:06:29,430 --> 00:06:32,840 one year to do this or one machine 1,000 years to do it. 111 00:06:32,840 --> 00:06:36,590 So you see that the y-axis here is going up exponentially. 112 00:06:36,590 --> 00:06:45,390 So to factor a 500 byte key is not that hard. 113 00:06:45,390 --> 00:06:47,920 It takes maybe a few months of compute time to do it. 114 00:06:47,920 --> 00:06:50,370 To factor a 2,000 byte key takes this 115 00:06:50,370 --> 00:06:53,632 a ridiculously long time, ten to the 16th years it is going 116 00:06:53,632 --> 00:06:54,840 to take to factor this thing. 117 00:06:54,840 --> 00:06:58,020 So there is just no way that, at least modern computers, 118 00:06:58,020 --> 00:07:00,150 are ever going to be able to actually perform 119 00:07:00,150 --> 00:07:03,784 this factoring using currently known algorithms for factoring. 120 00:07:03,784 --> 00:07:05,450 It is, of course, possible that somebody 121 00:07:05,450 --> 00:07:07,666 will develop a very fast factoring algorithm 122 00:07:07,666 --> 00:07:09,790 or that there will be some fundamental breakthrough 123 00:07:09,790 --> 00:07:13,310 like quantum computing that will make it possible to factor 124 00:07:13,310 --> 00:07:14,190 very large numbers. 125 00:07:14,190 --> 00:07:17,549 But, at this point, this is sort of the estimate of how long 126 00:07:17,549 --> 00:07:18,590 it would take to do this. 127 00:07:18,590 --> 00:07:21,620 So, by using long keys, you can be sort of guaranteed 128 00:07:21,620 --> 00:07:25,630 that somebody won't be able to actually factor this number. 129 00:07:25,630 --> 00:07:30,950 So by using a factoring-based attack on RSA 130 00:07:30,950 --> 00:07:36,820 that sort of won't be able to break it in this way. 131 00:07:36,820 --> 00:07:39,490 The largest RSA number that has been factored to date 132 00:07:39,490 --> 00:07:43,530 is some 500 odd byes, something like 520 bytes, 133 00:07:43,530 --> 00:07:45,422 so RSA has challenges for the largest 134 00:07:45,422 --> 00:07:46,630 numbers that can be factored. 135 00:07:46,630 --> 00:07:51,837 So we're sort of just barely on this curve 136 00:07:51,837 --> 00:07:53,420 is where the largest numbers that have 137 00:07:53,420 --> 00:07:54,336 been factored to date. 138 00:07:54,336 --> 00:07:56,000 And these are typically some collection 139 00:07:56,000 --> 00:07:57,166 of machines on the Internet. 140 00:07:57,166 --> 00:07:59,171 Somebody gets 1,000 machines on the Internet 141 00:07:59,171 --> 00:08:00,420 and they chew on this problem. 142 00:08:00,420 --> 00:08:02,880 I think, in this case, it took 1,000 machines three months 143 00:08:02,880 --> 00:08:10,660 to find a factor of this 500 byte key. 144 00:08:10,660 --> 00:08:11,970 This is the basic idea now. 145 00:08:11,970 --> 00:08:21,290 What we're going to do is use these cryptography algorithms, 146 00:08:21,290 --> 00:08:24,280 this math to build up a set of primitives 147 00:08:24,280 --> 00:08:26,600 that we can use to actually accomplish our security 148 00:08:26,600 --> 00:08:28,452 goals that we want. 149 00:08:28,452 --> 00:08:30,410 And I put these on the board briefly last time. 150 00:08:30,410 --> 00:08:31,868 But I didn't talk at all about what 151 00:08:31,868 --> 00:08:33,169 the actual functionality is. 152 00:08:33,169 --> 00:08:35,720 And we're going to spend a lot of time talking about two 153 00:08:35,720 --> 00:08:38,179 of these primitives today, and then we'll 154 00:08:38,179 --> 00:08:40,620 talk about a few more of them next time. 155 00:08:48,937 --> 00:08:50,770 We have two sets of primitives in particular 156 00:08:50,770 --> 00:08:52,070 that we are interested in. 157 00:08:55,550 --> 00:08:59,600 One set is called sign and verify. 158 00:08:59,600 --> 00:09:03,600 And the other set is called encrypt or decrypt. 159 00:09:07,990 --> 00:09:10,600 And we're going to use sign and verify basically as a way 160 00:09:10,600 --> 00:09:11,966 to achieve authentications. 161 00:09:11,966 --> 00:09:13,590 Remember, authentication is the process 162 00:09:13,590 --> 00:09:16,070 of verifying that a message actually came from who 163 00:09:16,070 --> 00:09:17,780 it was supposed to come from. 164 00:09:17,780 --> 00:09:21,832 And we're going to use encrypt and decrypt in order 165 00:09:21,832 --> 00:09:24,290 to provide confidentiality to guaranty that somebody who we 166 00:09:24,290 --> 00:09:27,540 don't want to be able to read a message, somebody who shouldn't 167 00:09:27,540 --> 00:09:31,660 be able to read a message can, in fact, not read that message. 168 00:09:31,660 --> 00:09:37,490 Let me just illustrate a simple example. 169 00:09:37,490 --> 00:09:43,090 Suppose we're using a public key system, 170 00:09:43,090 --> 00:09:46,700 we can say suppose we use something 171 00:09:46,700 --> 00:09:53,270 like RSA to encode a message m with some key, 172 00:09:53,270 --> 00:09:56,750 say we're sending a message from A to B, 173 00:09:56,750 --> 00:10:03,860 we use it to encode some key, say, kA private. 174 00:10:03,860 --> 00:10:07,690 What this notation means is that whoever 175 00:10:07,690 --> 00:10:11,280 has A's private key encodes that message or transforms 176 00:10:11,280 --> 00:10:15,180 that message using a cryptographic protocol using, 177 00:10:15,180 --> 00:10:17,220 say, for example, kA private. 178 00:10:17,220 --> 00:10:20,570 What this says is Alice, perhaps as A, 179 00:10:20,570 --> 00:10:23,120 runs her RSA algorithm on the message 180 00:10:23,120 --> 00:10:25,060 and generates some encoded thing. 181 00:10:27,970 --> 00:10:33,705 This is an encryption. 182 00:10:36,620 --> 00:10:39,000 We're going to use this encoding with the private key 183 00:10:39,000 --> 00:10:41,900 to sign a message. 184 00:10:41,900 --> 00:10:45,580 When Alice encodes this with her private key 185 00:10:45,580 --> 00:10:48,370 what that means is that somebody who has Alice's public key 186 00:10:48,370 --> 00:10:51,710 can decode this, because we said if you 187 00:10:51,710 --> 00:10:55,531 encode with the private key somebody with the public key 188 00:10:55,531 --> 00:10:56,030 can decode. 189 00:10:59,710 --> 00:11:01,510 For example, if she sends this to Bob, 190 00:11:01,510 --> 00:11:03,774 Bob is going to be able to decode this. 191 00:11:03,774 --> 00:11:06,190 At first that seems like, well, what good does that do us? 192 00:11:06,190 --> 00:11:08,010 Bob can read this message. 193 00:11:08,010 --> 00:11:10,540 But the thing is if Bob can decode 194 00:11:10,540 --> 00:11:13,610 this, what he knows, with very high certainty is 195 00:11:13,610 --> 00:11:15,640 that the person who encoded this message 196 00:11:15,640 --> 00:11:17,710 had access to A's private key. 197 00:11:17,710 --> 00:11:20,320 If he is willing to trust that, in fact, the only person who 198 00:11:20,320 --> 00:11:23,580 has access to A's private key is A herself, 199 00:11:23,580 --> 00:11:25,450 then he can be reasonably confident 200 00:11:25,450 --> 00:11:27,520 that this message came from A. 201 00:11:27,520 --> 00:11:31,870 You guys all sort of see how that works. 202 00:11:31,870 --> 00:11:36,110 What we say is that Alice signs this message. 203 00:11:36,110 --> 00:11:38,550 And, by signing this message, she 204 00:11:38,550 --> 00:11:41,810 is able to sort of give Bob some confidence 205 00:11:41,810 --> 00:11:43,560 that this message, in fact, came from her. 206 00:11:46,370 --> 00:11:49,390 We can also do the opposite thing 207 00:11:49,390 --> 00:11:53,640 where, say, for example, Alice is sending a message to Bob. 208 00:11:53,640 --> 00:11:58,225 She can take m and sign it with kB public. 209 00:12:00,800 --> 00:12:04,950 Sorry, she can encrypt it with kB public. 210 00:12:04,950 --> 00:12:07,380 She is going to use the RSA algorithm. 211 00:12:07,380 --> 00:12:08,922 She is going to encrypt this message. 212 00:12:08,922 --> 00:12:10,421 And, when she encrypts this message, 213 00:12:10,421 --> 00:12:12,760 she is going to basically use the RSA algorithm using 214 00:12:12,760 --> 00:12:13,990 kB public. 215 00:12:13,990 --> 00:12:15,700 And what is going to happen is now 216 00:12:15,700 --> 00:12:18,690 she is going to be reasonably assured that this message is 217 00:12:18,690 --> 00:12:20,850 going to be able to only be read by Bob 218 00:12:20,850 --> 00:12:24,650 because only Bob presumably has his own private key. 219 00:12:27,300 --> 00:12:29,450 What I've shown here makes this look very simple. 220 00:12:29,450 --> 00:12:31,810 I sort of said it as though we're simply 221 00:12:31,810 --> 00:12:35,050 taking this message and running the basic RSA algorithm, 222 00:12:35,050 --> 00:12:38,420 as I showed it, on the message in order to do sign 223 00:12:38,420 --> 00:12:39,450 and in order to encrypt. 224 00:12:39,450 --> 00:12:42,620 It turns out that actually getting sign and encrypt 225 00:12:42,620 --> 00:12:48,380 to work property requires some fairly sophisticated sort 226 00:12:48,380 --> 00:12:50,670 of reasoning about the RSA algorithm. 227 00:12:50,670 --> 00:12:53,730 For example, when you're encrypting something, 228 00:12:53,730 --> 00:12:55,910 if the message is very small, it turns out 229 00:12:55,910 --> 00:12:59,410 that if you encrypt a small message simply using the RSA 230 00:12:59,410 --> 00:13:02,620 algorithm as I presented it that it's relatively easy to break 231 00:13:02,620 --> 00:13:03,430 the RSA algorithm. 232 00:13:03,430 --> 00:13:05,640 The RSA algorithm becomes vulnerable with very small 233 00:13:05,640 --> 00:13:06,550 messages. 234 00:13:06,550 --> 00:13:08,380 That means the encryption process actually 235 00:13:08,380 --> 00:13:11,080 needs to pad out the message to some longer link. 236 00:13:11,080 --> 00:13:14,030 It needs to put unused bytes at the end of every message 237 00:13:14,030 --> 00:13:15,840 in order for it to be secure. 238 00:13:15,840 --> 00:13:19,500 These sign and encrypt algorithms themselves sort of 239 00:13:19,500 --> 00:13:22,020 have to do some additional work on top of the basic RSA 240 00:13:22,020 --> 00:13:23,870 algorithm in order to be secure. 241 00:13:23,870 --> 00:13:26,150 And that additional work is sort of 242 00:13:26,150 --> 00:13:27,470 beyond the scope of this class. 243 00:13:27,470 --> 00:13:30,080 It requires a certain degree of mathematical sophistication 244 00:13:30,080 --> 00:13:31,899 that we are not going to rely on here. 245 00:13:31,899 --> 00:13:33,940 You can go take an extra class about cryptography 246 00:13:33,940 --> 00:13:37,810 and learn about how these sign and encrypt algorithms actually 247 00:13:37,810 --> 00:13:40,950 work, but the basic idea is that you can sort of grasp it 248 00:13:40,950 --> 00:13:44,870 by just seeing RSA. 249 00:13:44,870 --> 00:13:48,130 These things are hard to build. 250 00:13:55,540 --> 00:13:58,780 Now that we have sort of quickly reviewed 251 00:13:58,780 --> 00:14:00,960 the basics of protection and we've 252 00:14:00,960 --> 00:14:09,706 seen the sign and verify and encrypt and decrypt primitives, 253 00:14:09,706 --> 00:14:11,580 now what I want to do is to talk a little bit 254 00:14:11,580 --> 00:14:15,470 about how we can actually start building up, solving 255 00:14:15,470 --> 00:14:18,990 this problem of authenticating a user. 256 00:14:18,990 --> 00:14:23,810 When we authenticate a user we have two objectives. 257 00:14:23,810 --> 00:14:33,160 One thing we're trying to achieve 258 00:14:33,160 --> 00:14:35,335 is to determine who is making a request. 259 00:14:44,390 --> 00:14:45,890 In practice, it's going to turn out, 260 00:14:45,890 --> 00:14:47,900 in fact, that we may not officially 261 00:14:47,900 --> 00:14:51,790 be able to say exactly the specific person who is being 262 00:14:51,790 --> 00:14:52,970 able to make the request. 263 00:14:52,970 --> 00:15:02,660 We may only be able to say that the same principle or person 264 00:15:02,660 --> 00:15:07,480 or computer as before is making the request, 265 00:15:07,480 --> 00:15:10,820 or the same principle who had some special privileged piece 266 00:15:10,820 --> 00:15:13,780 of information that the person before 267 00:15:13,780 --> 00:15:15,794 had is making this request. 268 00:15:15,794 --> 00:15:17,460 We may not be able to actually associate 269 00:15:17,460 --> 00:15:20,330 this with a physical person, but at least we're 270 00:15:20,330 --> 00:15:23,220 going to be able to know that we've seen somebody who had 271 00:15:23,220 --> 00:15:24,492 this same information before. 272 00:15:24,492 --> 00:15:25,950 We're trying to make sure that this 273 00:15:25,950 --> 00:15:28,300 is sort of consistent with a series of requests 274 00:15:28,300 --> 00:15:29,670 that we've seen in the past. 275 00:15:29,670 --> 00:15:35,680 A simple example is I lot onto Amazon, I create a password. 276 00:15:35,680 --> 00:15:37,620 Now, anybody who I give that password to 277 00:15:37,620 --> 00:15:39,110 can log onto Amazon. 278 00:15:39,110 --> 00:15:41,250 And all the system can say is that it 279 00:15:41,250 --> 00:15:46,050 knows that whoever it is who is accessing definitely 280 00:15:46,050 --> 00:15:49,680 has my password information and sort of it 281 00:15:49,680 --> 00:15:51,720 doesn't know officially that it is actually 282 00:15:51,720 --> 00:15:54,810 the same physical person. 283 00:15:54,810 --> 00:15:58,370 The other thing, though, that we want authentication to do 284 00:15:58,370 --> 00:16:09,830 is to tell us basically that the message that was sent 285 00:16:09,830 --> 00:16:12,395 is equal to the message that was received. 286 00:16:15,659 --> 00:16:17,950 We want it to be the case that if Alice sends a message 287 00:16:17,950 --> 00:16:20,044 to Bob, that when Bob receives that message, 288 00:16:20,044 --> 00:16:21,460 we want him to have some assurance 289 00:16:21,460 --> 00:16:24,290 that, in fact, that message was actually the message that Alice 290 00:16:24,290 --> 00:16:25,100 tried to send. 291 00:16:25,100 --> 00:16:28,330 And we're going to talk about how 292 00:16:28,330 --> 00:16:30,850 this is sort of going to relate to the problem of integrity 293 00:16:30,850 --> 00:16:33,350 that we talked about before, verifying that a message hasn't 294 00:16:33,350 --> 00:16:34,930 been corrupted in transmission. 295 00:16:34,930 --> 00:16:37,025 But this is actually a harder requirement 296 00:16:37,025 --> 00:16:38,650 because we might need to not only worry 297 00:16:38,650 --> 00:16:41,149 about sort of random bits being flipped by the communication 298 00:16:41,149 --> 00:16:44,280 channel but we need to worry about some malicious person 299 00:16:44,280 --> 00:16:46,299 coming in and physically actively modifying 300 00:16:46,299 --> 00:16:47,340 the bytes of the message. 301 00:16:51,290 --> 00:16:53,610 Authentication is sort of the first step 302 00:16:53,610 --> 00:16:55,330 that we need to have in any secure system 303 00:16:55,330 --> 00:16:58,300 because authentication is going to be the key. 304 00:16:58,300 --> 00:17:00,080 We have to authenticate a user before we 305 00:17:00,080 --> 00:17:01,436 can authorize the user. 306 00:17:01,436 --> 00:17:03,310 Before we can say, yes, this user is allowed, 307 00:17:03,310 --> 00:17:05,470 we have to figure out who the user is. 308 00:17:05,470 --> 00:17:09,640 And, similarly, we can use authentication, this process 309 00:17:09,640 --> 00:17:11,420 of figuring out who a user is to help 310 00:17:11,420 --> 00:17:12,795 us to build up audit trails. 311 00:17:12,795 --> 00:17:14,170 Remember we said audit trails are 312 00:17:14,170 --> 00:17:15,119 something that is important. 313 00:17:15,119 --> 00:17:16,579 Once we figure out who a user is, 314 00:17:16,579 --> 00:17:18,846 we can keep logs of which user it was that connected 315 00:17:18,846 --> 00:17:19,470 to our machine. 316 00:17:24,510 --> 00:17:29,880 Let's look at a simple model of how authentication works. 317 00:17:35,572 --> 00:17:36,530 The idea is as follows. 318 00:17:36,530 --> 00:17:40,200 We have our principle, say, for example, 319 00:17:40,200 --> 00:17:50,940 a user who is sending a request to some server. 320 00:17:55,870 --> 00:18:00,390 And this request might be something, for example, 321 00:18:00,390 --> 00:18:03,540 like buy Apple stock. 322 00:18:06,710 --> 00:18:08,950 And the server's job is to determine 323 00:18:08,950 --> 00:18:12,150 whether this request is actually authentic, whether it actually 324 00:18:12,150 --> 00:18:14,600 came from the user it claims to come from 325 00:18:14,600 --> 00:18:16,457 and whether the message that was received 326 00:18:16,457 --> 00:18:18,040 is actually the message that was sent. 327 00:18:20,667 --> 00:18:22,250 The way it's going to do this is we're 328 00:18:22,250 --> 00:18:26,240 going to introduce something we call a guard that 329 00:18:26,240 --> 00:18:28,080 is at the front end of this server that 330 00:18:28,080 --> 00:18:29,820 takes in all the incoming requests and is 331 00:18:29,820 --> 00:18:31,780 in charge of authenticating them. 332 00:18:31,780 --> 00:18:36,370 And then this guard is going to dispatch results off 333 00:18:36,370 --> 00:18:40,310 to any of the services that the server provides. 334 00:18:40,310 --> 00:18:41,810 It is going to say if the request is 335 00:18:41,810 --> 00:18:46,980 authentic it is going to invoke the service that we need. 336 00:18:46,980 --> 00:18:49,390 In other words, this guard is the type of mediator 337 00:18:49,390 --> 00:18:51,980 that sits in between all the requests between the principle 338 00:18:51,980 --> 00:18:53,780 and the service that it is trying to access 339 00:18:53,780 --> 00:18:55,571 and the guard is going to be the thing that 340 00:18:55,571 --> 00:19:10,410 does all of our authentication. 341 00:19:10,410 --> 00:19:14,569 Now the question is what is it exactly that the guard does? 342 00:19:14,569 --> 00:19:16,110 What are the processes that the guard 343 00:19:16,110 --> 00:19:20,070 has to go through in order to authenticate a user? 344 00:19:20,070 --> 00:19:23,300 And, before we talk about the specific technical solution, 345 00:19:23,300 --> 00:19:25,910 I want to sort about two things that are really 346 00:19:25,910 --> 00:19:29,992 going on when you're trying to figure out 347 00:19:29,992 --> 00:19:31,950 who it is that is requesting and whether you're 348 00:19:31,950 --> 00:19:34,199 going to allow that person to do what they want to do. 349 00:19:37,200 --> 00:19:39,170 So the issue is, essentially, as follows. 350 00:19:39,170 --> 00:19:46,470 There is this question about is the computer that 351 00:19:46,470 --> 00:19:49,885 is making this request actually have the appropriate keys 352 00:19:49,885 --> 00:19:50,760 to make this request? 353 00:19:50,760 --> 00:19:52,010 Does it have the appropriate password 354 00:19:52,010 --> 00:19:53,580 to be allowed to make this request? 355 00:19:53,580 --> 00:19:54,955 Then there is this other question 356 00:19:54,955 --> 00:19:56,730 which is do I trust this user? 357 00:19:56,730 --> 00:20:00,450 Is this somebody who I want using my service? 358 00:20:00,450 --> 00:20:05,610 Suppose that I go to E*Trade and say I want to buy Apple. 359 00:20:05,610 --> 00:20:07,800 How does E*Trade decide whether or not it trusts me, 360 00:20:07,800 --> 00:20:10,258 whether I'm somebody who is allowed to buy Apple stock from 361 00:20:10,258 --> 00:20:11,070 them or not? 362 00:20:11,070 --> 00:20:13,576 So they have some process for doing that. 363 00:20:13,576 --> 00:20:15,700 You have this mechanical process of authentication. 364 00:20:20,280 --> 00:20:25,230 And then we have this sort of psychological process 365 00:20:25,230 --> 00:20:28,160 of determining whether or not you trust somebody. 366 00:20:28,160 --> 00:20:33,880 So this authentication is going to be a technical thing 367 00:20:33,880 --> 00:20:36,770 and we are going to describe this as being psychological. 368 00:20:36,770 --> 00:20:50,070 What these things are connected by is some notion of a name. 369 00:20:50,070 --> 00:20:52,990 What the authentication says is, for example, 370 00:20:52,990 --> 00:20:54,520 Sam wants to buy Apple. 371 00:20:54,520 --> 00:20:57,600 It determines that I am, in fact, the person who 372 00:20:57,600 --> 00:21:01,760 is making the request, that it is 373 00:21:01,760 --> 00:21:04,240 able to verify that I am the one who is actually 374 00:21:04,240 --> 00:21:05,874 making the request. 375 00:21:05,874 --> 00:21:07,290 What trust is responsible of doing 376 00:21:07,290 --> 00:21:09,456 is determining whether or not Sam should actually be 377 00:21:09,456 --> 00:21:10,830 allowed to make this request. 378 00:21:10,830 --> 00:21:13,190 And this is not something that we necessarily 379 00:21:13,190 --> 00:21:14,660 have a technical solution to. 380 00:21:17,164 --> 00:21:19,080 Different computer systems have different ways 381 00:21:19,080 --> 00:21:21,640 of determining whether or not they should trust each other. 382 00:21:21,640 --> 00:21:26,817 For example, when you go to a service on the Web, 383 00:21:26,817 --> 00:21:29,150 you make a decision about whether you trust that service 384 00:21:29,150 --> 00:21:32,009 based on some sort of way that you 385 00:21:32,009 --> 00:21:33,300 have of evaluating the service. 386 00:21:33,300 --> 00:21:36,420 Maybe your Mom told you that E*Trade is the best place 387 00:21:36,420 --> 00:21:38,450 to buy stocks on the Internet with. 388 00:21:38,450 --> 00:21:41,330 You trust your Mom and so, therefore, you trust E*Trade. 389 00:21:41,330 --> 00:21:43,320 Or maybe you saw an advertisement for E*Trade 390 00:21:43,320 --> 00:21:46,500 and you think any company that has enough money to advertise 391 00:21:46,500 --> 00:21:49,680 on the side of the freeway must be a trustworthy company 392 00:21:49,680 --> 00:21:51,700 and, therefore, I trust you. 393 00:21:51,700 --> 00:21:55,650 Similarly, E*Trade, presumably determines that they trust you 394 00:21:55,650 --> 00:21:57,890 based on, well, one thing they might do is, 395 00:21:57,890 --> 00:21:59,640 you might give them a bank account number, 396 00:21:59,640 --> 00:22:02,056 and your bank might say, yes, this person has enough money 397 00:22:02,056 --> 00:22:03,210 to make this request. 398 00:22:03,210 --> 00:22:06,360 That is a way that they might decide that they trust you. 399 00:22:06,360 --> 00:22:09,550 Alternatively, E*Trade gives out loans, 400 00:22:09,550 --> 00:22:12,950 so maybe they go talk to your credit reporting agency, 401 00:22:12,950 --> 00:22:15,280 and the credit reporting agency says, yeah, 402 00:22:15,280 --> 00:22:16,970 this guy is trustworthy. 403 00:22:16,970 --> 00:22:21,556 He has a high credit score so, therefore, 404 00:22:21,556 --> 00:22:23,930 E*Trade will let you borrow $1,000 to invest in the stock 405 00:22:23,930 --> 00:22:24,763 market or something. 406 00:22:27,250 --> 00:22:29,002 This issue of trust is one that we 407 00:22:29,002 --> 00:22:30,460 don't have a technical solution to, 408 00:22:30,460 --> 00:22:32,240 but it is absolutely an essential part 409 00:22:32,240 --> 00:22:34,529 of authenticating and authorizing a user 410 00:22:34,529 --> 00:22:35,570 to use a computer system. 411 00:22:35,570 --> 00:22:37,840 So it's worth just bearing this in mind 412 00:22:37,840 --> 00:22:40,150 that any time you're building a computer 413 00:22:40,150 --> 00:22:43,120 system you need to think about how 414 00:22:43,120 --> 00:22:45,896 it is that you determine whether a user is trustworthy or not. 415 00:22:45,896 --> 00:22:48,270 And this goes both ways, both for the user of the system, 416 00:22:48,270 --> 00:22:49,870 how do they determine that you're trustworthy, 417 00:22:49,870 --> 00:22:51,690 and for the system, how do you determine 418 00:22:51,690 --> 00:22:52,981 that the users are trustworthy? 419 00:22:58,230 --> 00:23:01,570 Now the key problem is focusing on this sort 420 00:23:01,570 --> 00:23:02,920 of authentication problem. 421 00:23:02,920 --> 00:23:06,072 What is the technical meat of how we're actually 422 00:23:06,072 --> 00:23:07,280 going to authenticate a user? 423 00:23:19,730 --> 00:23:22,250 One of these problems is determining 424 00:23:22,250 --> 00:23:24,370 that this message that was sent was actually 425 00:23:24,370 --> 00:23:25,869 the message that was received. 426 00:23:25,869 --> 00:23:27,660 Here is a simply proposal that I might have 427 00:23:27,660 --> 00:23:33,472 which is I might compute one of these CRC checks. 428 00:23:33,472 --> 00:23:35,180 These checksums that we talked about when 429 00:23:35,180 --> 00:23:37,596 we were talking about networking that we used to determine 430 00:23:37,596 --> 00:23:41,370 whether or not the message has been corrupted in transmission. 431 00:23:41,370 --> 00:23:43,780 It turns out that is not going to work. 432 00:23:43,780 --> 00:23:45,720 You might also think the way that you 433 00:23:45,720 --> 00:23:48,360 are going to insure that the person who is requesting 434 00:23:48,360 --> 00:23:52,350 the message is actually who they claim to be 435 00:23:52,350 --> 00:23:57,390 is, for example, using our encryption primitive. 436 00:23:57,390 --> 00:24:00,230 If we had a one time pad available to us, 437 00:24:00,230 --> 00:24:01,782 we might encrypt the entire stream 438 00:24:01,782 --> 00:24:02,990 of data that is going across. 439 00:24:02,990 --> 00:24:04,130 And then we would think well, there 440 00:24:04,130 --> 00:24:05,490 is no way that somebody on the other end, 441 00:24:05,490 --> 00:24:07,400 unless they are authorized to read this, 442 00:24:07,400 --> 00:24:10,230 will actually be able to read it. 443 00:24:10,230 --> 00:24:14,014 And, therefore, this is going to give us some guaranty about who 444 00:24:14,014 --> 00:24:14,930 is making the request. 445 00:24:14,930 --> 00:24:17,430 Neither of these things quite works, and let me explain why. 446 00:24:19,850 --> 00:24:23,600 Integrity, in the sense that we studied it previously in 6.033, 447 00:24:23,600 --> 00:24:31,263 is not equal to authenticity, is not equal to confidentiality. 448 00:24:37,840 --> 00:24:39,150 And the reason is as follows. 449 00:24:39,150 --> 00:24:41,660 Let's just look at a simple example. 450 00:24:41,660 --> 00:24:45,530 Suppose there is Alice who is sending 451 00:24:45,530 --> 00:24:51,390 a message to some server, and suppose this server 452 00:24:51,390 --> 00:24:53,030 is something where Alice doesn't really 453 00:24:53,030 --> 00:24:55,550 mind if her request is seen in public 454 00:24:55,550 --> 00:25:01,897 but she wants to make sure that the server actually receives 455 00:25:01,897 --> 00:25:02,980 the request that she made. 456 00:25:02,980 --> 00:25:04,896 So she cares about it being the right request, 457 00:25:04,896 --> 00:25:07,700 but she doesn't care about it being a secret request. 458 00:25:07,700 --> 00:25:18,850 Maybe Alice says I want to donate $100 to Save the Whales. 459 00:25:18,850 --> 00:25:22,189 She says I don't care if anybody knows 460 00:25:22,189 --> 00:25:23,480 that I want to save the whales. 461 00:25:23,480 --> 00:25:25,540 That's a noble and respectful cause. 462 00:25:25,540 --> 00:25:29,080 In fact, I am proud of the fact that I want to save the whales. 463 00:25:29,080 --> 00:25:31,170 So anybody who wants to can look at this message. 464 00:25:31,170 --> 00:25:33,802 But I really only want to give Save the Whales $100. 465 00:25:33,802 --> 00:25:35,510 I want to make sure that somebody doesn't 466 00:25:35,510 --> 00:25:39,000 mess with this message and some Save the Whale activist doesn't 467 00:25:39,000 --> 00:25:41,170 change this message to be $10,000 so that I 468 00:25:41,170 --> 00:25:45,400 don't lose a bunch of money. 469 00:25:45,400 --> 00:25:47,350 Let's look at some techniques that we 470 00:25:47,350 --> 00:25:51,000 might use to sort of guaranty that this is the case. 471 00:25:51,000 --> 00:25:57,550 One thing we might do is, for example, use a one time pad. 472 00:25:57,550 --> 00:26:00,990 Suppose Alice and the server share a random bit string. 473 00:26:00,990 --> 00:26:07,210 Alice might encode, might xor the message that she transmits, 474 00:26:07,210 --> 00:26:10,447 and then the server might apply the xor again 475 00:26:10,447 --> 00:26:12,530 with the same bit string and get the message back. 476 00:26:15,050 --> 00:26:18,640 The problem with this is that this 477 00:26:18,640 --> 00:26:22,580 doesn't prevent some malicious user or Lucifer 478 00:26:22,580 --> 00:26:24,540 from coming into the middle of this 479 00:26:24,540 --> 00:26:27,187 and interfering with this byte string as it is transmitted. 480 00:26:27,187 --> 00:26:29,520 Even though Lucifer cannot actually look at the message, 481 00:26:29,520 --> 00:26:31,603 he can manipulate the byes to his heart's content. 482 00:26:31,603 --> 00:26:34,874 And he may get lucky and change the bytes so that it says 483 00:26:34,874 --> 00:26:37,040 something like donate some different amount of money 484 00:26:37,040 --> 00:26:40,250 to save the whales or he may just garble Alice's requests 485 00:26:40,250 --> 00:26:41,680 so it cannot be processed. 486 00:26:41,680 --> 00:26:45,590 So one time pad is not going to work. 487 00:26:45,590 --> 00:26:48,580 Now, the other alternative I said we can talk about 488 00:26:48,580 --> 00:26:52,750 would be something like using a CRC. 489 00:26:52,750 --> 00:26:59,430 What Alice would do is send m followed by the CRC of m. 490 00:26:59,430 --> 00:27:01,711 The problem with this is that now Lucifer 491 00:27:01,711 --> 00:27:03,210 can look at this message as it comes 492 00:27:03,210 --> 00:27:04,920 across the wire and the checksum, 493 00:27:04,920 --> 00:27:06,590 and he can simply change the message 494 00:27:06,590 --> 00:27:09,680 to say whatever he wants and then recomputed the checksum. 495 00:27:09,680 --> 00:27:11,950 So the checksums, as we have talked about them so far, 496 00:27:11,950 --> 00:27:15,820 are good for handling the case of non-malicious attacks 497 00:27:15,820 --> 00:27:18,380 or non-malicious problems like a byte gets changed 498 00:27:18,380 --> 00:27:21,050 in transmission or there is some error in transmission, 499 00:27:21,050 --> 00:27:24,692 but they don't solve this problem of preventing somebody 500 00:27:24,692 --> 00:27:26,400 from tampering with the message and being 501 00:27:26,400 --> 00:27:30,570 able to detect when that tampering also effects the CRC. 502 00:27:34,890 --> 00:27:36,680 If you think about this for a minute, 503 00:27:36,680 --> 00:27:38,360 the property that we want sort of 504 00:27:38,360 --> 00:27:40,440 feels like some combination of these two things. 505 00:27:40,440 --> 00:27:48,100 Basically, what we want is some checksum-like operation such 506 00:27:48,100 --> 00:27:53,310 that we know that the only person who could have possibly 507 00:27:53,310 --> 00:27:58,540 written this checksum was somebody who access to some key 508 00:27:58,540 --> 00:28:00,780 that Alice has like Alice's private key. 509 00:28:00,780 --> 00:28:12,040 We want a checksum that is dependent on a key, 510 00:28:12,040 --> 00:28:13,690 and we want this checksum to have 511 00:28:13,690 --> 00:28:16,904 some fairly strong properties. 512 00:28:16,904 --> 00:28:19,070 We want this checksum to be resistant to these kinds 513 00:28:19,070 --> 00:28:23,280 of attacks that we talked about Lucifer applying. 514 00:28:23,280 --> 00:28:25,010 In particular, we want the checksum 515 00:28:25,010 --> 00:28:29,150 to be resistant to Lucifer modifying the message. 516 00:28:29,150 --> 00:28:31,770 So the checksum should detect that this message was 517 00:28:31,770 --> 00:28:33,065 modified, if it was modified. 518 00:28:35,910 --> 00:28:40,170 We also want it to be able to detect other transformations 519 00:28:40,170 --> 00:28:41,730 of the message. 520 00:28:41,730 --> 00:28:45,720 For example, suppose that rather than modifying m, changing 521 00:28:45,720 --> 00:28:49,060 something, Lucifer just reorders some of the words in it, 522 00:28:49,060 --> 00:28:51,310 keeps exactly the same characters and exactly 523 00:28:51,310 --> 00:28:53,880 the same length but just switches some things around. 524 00:28:56,942 --> 00:28:58,400 And there are other kinds of things 525 00:28:58,400 --> 00:29:01,100 that we might want to be able to resist as well. 526 00:29:01,100 --> 00:29:03,452 For example, taking exactly the same message 527 00:29:03,452 --> 00:29:05,910 and sticking a little bit of extra data onto the end of it, 528 00:29:05,910 --> 00:29:07,620 appending something to the message. 529 00:29:07,620 --> 00:29:09,620 There is a bunch of different sort of properties 530 00:29:09,620 --> 00:29:11,590 that we want whatever this thing is 531 00:29:11,590 --> 00:29:16,690 that is going to allow us to do authentication to have. 532 00:29:16,690 --> 00:29:20,960 Let's look at the sort of model for how 533 00:29:20,960 --> 00:29:23,412 our basic authentication system is going to work. 534 00:29:23,412 --> 00:29:24,870 It is really pretty straightforward 535 00:29:24,870 --> 00:29:27,120 and is going to rely on using our sign 536 00:29:27,120 --> 00:29:29,680 and verify primitives that I am erasing. 537 00:29:35,760 --> 00:29:37,070 The idea is as follows. 538 00:29:37,070 --> 00:29:39,340 We have Alice over here that is sending a message. 539 00:29:42,400 --> 00:29:45,400 That message is going to go into our sign 540 00:29:45,400 --> 00:29:48,470 cryptographic primitive, it's going to be transformed 541 00:29:48,470 --> 00:29:52,770 and is going to come over here to our verify box, 542 00:29:52,770 --> 00:29:55,810 and then it is going to come out on the other side 543 00:29:55,810 --> 00:29:58,125 at the server. 544 00:30:01,260 --> 00:30:04,580 And the sign is going to have some k1 that gets fed into it 545 00:30:04,580 --> 00:30:07,700 and verify is going to have some k2 that gets fed into it. 546 00:30:07,700 --> 00:30:10,530 And the idea is that in addition to signing the message 547 00:30:10,530 --> 00:30:13,860 we are also going to transmit the message itself. 548 00:30:13,860 --> 00:30:16,460 So this is going to be sort of like this idea of putting 549 00:30:16,460 --> 00:30:18,030 a CRC on a message, but this thing 550 00:30:18,030 --> 00:30:19,904 that we are going to do when we sign is going 551 00:30:19,904 --> 00:30:23,150 to provide this sort of better properties than the basic CRC 552 00:30:23,150 --> 00:30:23,760 did. 553 00:30:23,760 --> 00:30:26,260 The idea is this is a small bit of additional information 554 00:30:26,260 --> 00:30:28,960 that gets transmitted with the message that allows the server 555 00:30:28,960 --> 00:30:31,270 to be confident that, in fact, the message that 556 00:30:31,270 --> 00:30:34,472 was transmitted came from Alice and that it has not 557 00:30:34,472 --> 00:30:35,680 been corrupted along the way. 558 00:30:45,720 --> 00:30:53,522 This is the basic idea now k1 comes in, it gets transmitted, 559 00:30:53,522 --> 00:30:55,480 goes through the verify box, and the verify box 560 00:30:55,480 --> 00:30:58,800 reports yes or no, this message was correct or was not correct. 561 00:30:58,800 --> 00:31:00,980 And the server also has access to the message. 562 00:31:00,980 --> 00:31:02,730 If the server gets yes in the message then 563 00:31:02,730 --> 00:31:07,590 it continues to process it. 564 00:31:07,590 --> 00:31:10,160 And we have two kinds of ways of doing authentification 565 00:31:10,160 --> 00:31:14,570 that correspond to shared key and public key cryptography. 566 00:31:14,570 --> 00:31:21,287 If k1 is equal to k2 we say that this little bit of information 567 00:31:21,287 --> 00:31:23,745 that we have transmitted is a MAC, a message authenticator. 568 00:31:26,950 --> 00:31:30,024 When you are using shared key cryptography that 569 00:31:30,024 --> 00:31:31,940 is the bit of additional information that gets 570 00:31:31,940 --> 00:31:33,360 transmitted. 571 00:31:33,360 --> 00:31:36,050 And when k1 is not equal to k2, that 572 00:31:36,050 --> 00:31:38,180 is if we're using public key cryptography, 573 00:31:38,180 --> 00:31:42,440 we call this bit of additional information a signature. 574 00:31:46,750 --> 00:31:48,290 To give you a very simple example 575 00:31:48,290 --> 00:31:50,830 of what a signature might consist of, suppose we have 576 00:31:50,830 --> 00:31:52,710 a message m. 577 00:31:52,710 --> 00:31:54,970 In public key cryptography, a simple kind 578 00:31:54,970 --> 00:31:56,530 of signature that you can compute 579 00:31:56,530 --> 00:32:00,630 is to take the hash of m. 580 00:32:00,630 --> 00:32:06,260 And then take that thing and encode it 581 00:32:06,260 --> 00:32:10,760 with Alice's private key. 582 00:32:10,760 --> 00:32:13,590 This is a simple kind of a signature 583 00:32:13,590 --> 00:32:15,250 that we might attach to a message. 584 00:32:15,250 --> 00:32:16,840 And this has the properties we want, 585 00:32:16,840 --> 00:32:23,734 which is that we believe that only Alice could have actually 586 00:32:23,734 --> 00:32:26,150 encoded this message because we belief that only Alice has 587 00:32:26,150 --> 00:32:28,390 access to her private key. 588 00:32:28,390 --> 00:32:32,560 And so when somebody uses the public key to decode this 589 00:32:32,560 --> 00:32:42,720 they get something back which is a hash of the message. 590 00:32:42,720 --> 00:32:44,990 And we call this a cryptographically secure hash. 591 00:32:49,530 --> 00:32:59,070 It is some way of combining the bits of the message 592 00:32:59,070 --> 00:33:03,600 together such that when the server computes the hash of m, 593 00:33:03,600 --> 00:33:06,300 the probability that it matches this hash that 594 00:33:06,300 --> 00:33:10,950 was in the signature that Alice sent, 595 00:33:10,950 --> 00:33:13,500 they will match if the messages are the same. 596 00:33:13,500 --> 00:33:16,490 And, if the hash was computed on a different message 597 00:33:16,490 --> 00:33:18,240 than the message that the server receives, 598 00:33:18,240 --> 00:33:20,150 the probability is very, very low 599 00:33:20,150 --> 00:33:22,672 that these two messages are, in fact, the same. 600 00:33:22,672 --> 00:33:24,630 So they say it has a low collision probability. 601 00:33:24,630 --> 00:33:29,140 It's very unlikely that some m prime that is not equal to m 602 00:33:29,140 --> 00:33:31,460 has the same hash as m. 603 00:33:31,460 --> 00:33:34,290 That's what a cryptographically secure hash provides us. 604 00:33:34,290 --> 00:33:37,400 And, again, cryptographically secure hashes 605 00:33:37,400 --> 00:33:39,940 are another kind of sort of mathematical technique. 606 00:33:39,940 --> 00:33:42,190 There is a set of algorithms for driving these things. 607 00:33:42,190 --> 00:33:45,910 The appendix talks about a common one which is used 608 00:33:45,910 --> 00:33:47,700 called sha-1. 609 00:33:47,700 --> 00:33:50,260 And sha-1, it turns out, has recently 610 00:33:50,260 --> 00:33:53,080 been shown to have some higher probability of collisions 611 00:33:53,080 --> 00:33:54,250 than was previously thought. 612 00:33:54,250 --> 00:33:56,399 And there is a new protocol called sha-256 613 00:33:56,399 --> 00:33:57,940 which is still believed to be secure. 614 00:33:57,940 --> 00:34:01,650 But sha-1, the S-H-A, which stands for secure hash, 615 00:34:01,650 --> 00:34:07,830 is one that is very commonly used in the world today. 616 00:34:07,830 --> 00:34:09,969 So this is a simple example of a signature 617 00:34:09,969 --> 00:34:12,469 and it allows basically for the server 618 00:34:12,469 --> 00:34:16,870 to verify one by decoding the message with Alice's public key 619 00:34:16,870 --> 00:34:19,400 that the message actually came from Alice, 620 00:34:19,400 --> 00:34:21,940 and this hash allows it to be reasonably assured 621 00:34:21,940 --> 00:34:25,219 that the message has not been tampered with. 622 00:34:25,219 --> 00:34:28,550 If the message had been tampered with the hash wouldn't match, 623 00:34:28,550 --> 00:34:32,000 and if this signature had been tampered with then 624 00:34:32,000 --> 00:34:34,400 the receiver wouldn't have been able to decode this thing 625 00:34:34,400 --> 00:34:36,840 and get something back that made any sense. 626 00:34:36,840 --> 00:34:40,440 Or, again, the hash probably wouldn't match. 627 00:34:40,440 --> 00:34:45,513 This is the basic solution for doing authentication. 628 00:34:48,520 --> 00:34:54,630 This screen is too low. 629 00:34:54,630 --> 00:35:00,140 Now that we've sort of seen a method 630 00:35:00,140 --> 00:35:02,110 for authenticating a message, there 631 00:35:02,110 --> 00:35:05,292 are sort of a bunch of little details that we left hanging. 632 00:35:05,292 --> 00:35:07,500 In particular, one of the details that we haven't yet 633 00:35:07,500 --> 00:35:12,700 addressed is, suppose we are using some public key based 634 00:35:12,700 --> 00:35:15,740 mechanism like this, I haven't yet told you 635 00:35:15,740 --> 00:35:19,020 or we haven't talked about how it is that somebody 636 00:35:19,020 --> 00:35:22,020 would learn Alice's public key? 637 00:35:22,020 --> 00:35:23,700 We sort of just assumed that whoever 638 00:35:23,700 --> 00:35:25,820 is receiving the message is able to figure out 639 00:35:25,820 --> 00:35:27,910 what Alice's public key is. 640 00:35:27,910 --> 00:35:30,840 And one thing you could imagine is that Alice goes around 641 00:35:30,840 --> 00:35:34,420 and physically meets everybody who she would ever 642 00:35:34,420 --> 00:35:36,000 want to give a key to and she hands 643 00:35:36,000 --> 00:35:38,520 them a slip of paper that has her public key written on it. 644 00:35:38,520 --> 00:35:41,680 But, obviously, one, that's not how the Internet works clearly 645 00:35:41,680 --> 00:35:43,900 because we have some cryptographic protocols that 646 00:35:43,900 --> 00:35:45,650 allow us, we don't have to meet everybody 647 00:35:45,650 --> 00:35:48,961 and we can still get established secure communication channels. 648 00:35:48,961 --> 00:35:50,960 And, two, that just doesn't sound very scalable. 649 00:35:50,960 --> 00:35:52,584 It doesn't sound like a great solution. 650 00:35:55,450 --> 00:35:59,200 This is the key distribution problem. 651 00:35:59,200 --> 00:36:01,450 This is going to apply mostly for the case 652 00:36:01,450 --> 00:36:04,390 of public key cryptography. 653 00:36:04,390 --> 00:36:10,424 In the case of shared key cryptography, 654 00:36:10,424 --> 00:36:12,340 this method I am going to show you in a minute 655 00:36:12,340 --> 00:36:13,970 is not going to apply necessarily 656 00:36:13,970 --> 00:36:15,928 to shared key cryptography, but I will show you 657 00:36:15,928 --> 00:36:18,810 a way in which we can use public key cryptography 658 00:36:18,810 --> 00:36:22,600 to sort of bootstrap or to exchange a shared key which 659 00:36:22,600 --> 00:36:26,120 we can then use over our communication channel. 660 00:36:26,120 --> 00:36:27,660 This is the key distribution problem 661 00:36:27,660 --> 00:36:29,395 for public key cryptographic systems. 662 00:36:39,170 --> 00:36:44,029 One solution, if Alice cannot physically meet with Bob, 663 00:36:44,029 --> 00:36:46,570 one thing that you might imagine doing is you could just have 664 00:36:46,570 --> 00:36:55,870 Alice send a message to Bob saying here is my public key. 665 00:36:55,870 --> 00:37:07,150 Or, better yet, Alice's public key is, A's public key is X. 666 00:37:07,150 --> 00:37:09,180 But this isn't a very good approach 667 00:37:09,180 --> 00:37:11,840 because how does B actually know that this was 668 00:37:11,840 --> 00:37:13,090 Alice that sent this message? 669 00:37:13,090 --> 00:37:15,610 This could have been some Lucifer who said, oh, 670 00:37:15,610 --> 00:37:17,260 by the way, Alice's key is this. 671 00:37:17,260 --> 00:37:20,680 And now B thinks that Alice's key is, in fact, Lucifer's key. 672 00:37:20,680 --> 00:37:22,590 And now Lucifer can decode any message 673 00:37:22,590 --> 00:37:24,190 that B wants to send to A. 674 00:37:24,190 --> 00:37:26,980 So this isn't really a very good approach 675 00:37:26,980 --> 00:37:31,170 because if A just, sort of out of the blue, 676 00:37:31,170 --> 00:37:33,400 blurts out to be my key is this then 677 00:37:33,400 --> 00:37:36,260 it doesn't have any way of actually knowing that this was, 678 00:37:36,260 --> 00:37:38,450 in fact, A who reported this key. 679 00:37:38,450 --> 00:37:39,980 That doesn't solve our problem. 680 00:37:39,980 --> 00:37:42,521 Instead, we are going to use a technique called certificates. 681 00:37:47,470 --> 00:37:48,640 Certificates work like this. 682 00:37:53,509 --> 00:37:55,050 The idea with certificates is that we 683 00:37:55,050 --> 00:37:57,140 are going to introduce a third-party who 684 00:37:57,140 --> 00:37:59,330 I have shown here as Charles. 685 00:37:59,330 --> 00:38:03,050 Let's suppose that Alice and Bob know and trust Charles. 686 00:38:03,050 --> 00:38:06,000 So they have already somehow exchanged information 687 00:38:06,000 --> 00:38:09,130 with Charles, exchanged keys with him. 688 00:38:09,130 --> 00:38:18,810 The idea is now suppose Alice wants to send a message to Bob. 689 00:38:18,810 --> 00:38:21,910 What she does is she sends this message, 690 00:38:21,910 --> 00:38:26,360 and she signs the message using her private key. 691 00:38:26,360 --> 00:38:30,150 That is what this S parentheses m kApriv means. 692 00:38:30,150 --> 00:38:32,710 Now what Bob is going to do is say, well, I 693 00:38:32,710 --> 00:38:35,220 don't know who this Alice is. 694 00:38:35,220 --> 00:38:36,924 And rather than simply asking Alice 695 00:38:36,924 --> 00:38:38,840 for her public key, which we have already said 696 00:38:38,840 --> 00:38:40,599 is not a very good idea, what Bob does 697 00:38:40,599 --> 00:38:42,140 is he asks Charles for her public key 698 00:38:42,140 --> 00:38:44,790 because he trusts Charles and he knows that Charles probably 699 00:38:44,790 --> 00:38:46,420 knows something about Alice. 700 00:38:46,420 --> 00:38:50,840 And what Charles responds with is Alice's public key, 701 00:38:50,840 --> 00:38:54,320 as well as he needs to make sure that he, himself, 702 00:38:54,320 --> 00:38:58,471 signs this message with his own private key so that somebody 703 00:38:58,471 --> 00:39:00,720 else cannot intercept the message as it is coming back 704 00:39:00,720 --> 00:39:02,240 and overwrite it. 705 00:39:02,240 --> 00:39:06,730 He put his signature on this message 706 00:39:06,730 --> 00:39:09,120 that he sends back with Alice's public key in it. 707 00:39:09,120 --> 00:39:11,430 Now Bob has Alice's public key, and he 708 00:39:11,430 --> 00:39:14,010 can go ahead and decode this message, 709 00:39:14,010 --> 00:39:16,880 he can go ahead and verify this message that Alice 710 00:39:16,880 --> 00:39:19,290 tried to send to him. 711 00:39:19,290 --> 00:39:21,360 So, in this, we call this Charles here, 712 00:39:21,360 --> 00:39:26,650 sometimes it is called a CA, a certificate authority. 713 00:39:26,650 --> 00:39:34,670 And the idea is that these CAs, a small number of CAs 714 00:39:34,670 --> 00:39:37,290 can service a very large number of users. 715 00:39:37,290 --> 00:39:40,250 So rather than having to have every user exchange keys 716 00:39:40,250 --> 00:39:42,207 with every other user, each user just 717 00:39:42,207 --> 00:39:44,290 exchanges keys with a few certificate authorities. 718 00:39:44,290 --> 00:39:46,456 And then, those certificate authorities, sort of act 719 00:39:46,456 --> 00:39:50,150 like these hubs that propagate keys out 720 00:39:50,150 --> 00:39:53,340 into the rest of the users. 721 00:39:56,774 --> 00:39:58,190 This is a very simple way in which 722 00:39:58,190 --> 00:40:00,106 you might be able to disseminate a public key. 723 00:40:00,106 --> 00:40:03,490 We will talk a little bit later on about sort 724 00:40:03,490 --> 00:40:05,350 of a more formal way of reasoning 725 00:40:05,350 --> 00:40:07,010 about how public keys are disseminated 726 00:40:07,010 --> 00:40:10,090 and how these kinds of webs of trust are built up, 727 00:40:10,090 --> 00:40:12,130 but this is just a simple way to sort 728 00:40:12,130 --> 00:40:15,050 of start thinking about how public keys might 729 00:40:15,050 --> 00:40:17,330 be disseminated automatically over the Internet. 730 00:40:22,390 --> 00:40:24,410 What I want to do now is just briefly turn, 731 00:40:24,410 --> 00:40:26,540 with the last few minutes, to this question 732 00:40:26,540 --> 00:40:33,710 of how we actually establish a secure communication 733 00:40:33,710 --> 00:40:36,340 channel between two parties. 734 00:40:36,340 --> 00:40:39,600 This is going to get at our property, 735 00:40:39,600 --> 00:40:42,160 the sort of establishing a confidential communication 736 00:40:42,160 --> 00:40:42,660 channel. 737 00:40:42,660 --> 00:40:43,950 We are going to talk a little bit about how 738 00:40:43,950 --> 00:40:45,205 we establish confidentiality. 739 00:40:48,930 --> 00:40:59,477 And so the idea is that we want to find 740 00:40:59,477 --> 00:41:02,060 some way that we can encrypt the communication between our two 741 00:41:02,060 --> 00:41:02,910 parties. 742 00:41:02,910 --> 00:41:05,260 And what we are going to do is first authenticate 743 00:41:05,260 --> 00:41:10,190 the user using a technique like this, 744 00:41:10,190 --> 00:41:17,780 and then what we are going to do is 745 00:41:17,780 --> 00:41:24,610 use public key to authenticate. 746 00:41:24,610 --> 00:41:33,380 This is establishing a secure communication channel. 747 00:41:33,380 --> 00:41:38,610 We are going to use public key to authenticate. 748 00:41:38,610 --> 00:41:41,240 But what often happens in practice 749 00:41:41,240 --> 00:41:44,266 in the Internet is that you use public key to authenticate, 750 00:41:44,266 --> 00:41:45,640 and then what you are going to do 751 00:41:45,640 --> 00:41:47,760 is use a shared key cryptography protocol 752 00:41:47,760 --> 00:41:49,780 to actually encrypt the information that 753 00:41:49,780 --> 00:41:52,090 is flowing back and forth between the two parties. 754 00:41:52,090 --> 00:41:54,890 And the reason for that is if you sort of looked at, 755 00:41:54,890 --> 00:41:59,350 even though I said that these public key methods like RSA, 756 00:41:59,350 --> 00:42:02,530 it's easier to exponentiate than it is to factor. 757 00:42:02,530 --> 00:42:04,660 It turns out that exponentiation in RSA 758 00:42:04,660 --> 00:42:07,010 is still relatively expensive because exponentiation 759 00:42:07,010 --> 00:42:08,952 requires, these keys are very long, they 760 00:42:08,952 --> 00:42:10,410 are thousands of bytes long, so you 761 00:42:10,410 --> 00:42:12,530 are taking these long messages and taking them 762 00:42:12,530 --> 00:42:14,700 to very large powers. 763 00:42:14,700 --> 00:42:16,390 Doing that is computationally expensive. 764 00:42:16,390 --> 00:42:18,480 You get these very big numbers that computers are not 765 00:42:18,480 --> 00:42:19,640 terribly good at handling. 766 00:42:19,640 --> 00:42:21,440 And so it has a big impact on performance 767 00:42:21,440 --> 00:42:24,940 if you use public key cryptography all the time. 768 00:42:24,940 --> 00:42:26,450 Instead, often times what is done 769 00:42:26,450 --> 00:42:29,260 is we use public key cryptography to sort of, 770 00:42:29,260 --> 00:42:32,160 as I said, bootstrap the process of exchanging a shared 771 00:42:32,160 --> 00:42:33,955 key between two servers. 772 00:42:33,955 --> 00:42:35,330 That is what we are going to see. 773 00:42:35,330 --> 00:42:43,190 We are going to see how we can then exchange a shared 774 00:42:43,190 --> 00:42:47,740 key which we can then use to encrypt the communication 775 00:42:47,740 --> 00:42:48,820 between two parties. 776 00:42:52,390 --> 00:42:54,060 This is a little puzzle for you guys. 777 00:42:54,060 --> 00:42:59,272 What I am going to put up now is a broken protocol 778 00:42:59,272 --> 00:43:01,730 and see if you can figure out, in the next few minutes, how 779 00:43:01,730 --> 00:43:02,630 it is broken. 780 00:43:02,630 --> 00:43:07,050 It is not very broken but it is broken in kind of a subtle way. 781 00:43:07,050 --> 00:43:08,790 This is a protocol called Denning-Sacco. 782 00:43:08,790 --> 00:43:10,360 And when it was originally proposed, 783 00:43:10,360 --> 00:43:12,860 the original proposers of it actually got it wrong, too. 784 00:43:12,860 --> 00:43:14,390 And they presumably thought about it for a while 785 00:43:14,390 --> 00:43:15,290 before they got it wrong. 786 00:43:15,290 --> 00:43:16,850 This is meant to be an illustration 787 00:43:16,850 --> 00:43:19,420 that designing cryptographic protocols is hard 788 00:43:19,420 --> 00:43:21,170 and it needs to be something that you need 789 00:43:21,170 --> 00:43:23,280 to think about very carefully. 790 00:43:23,280 --> 00:43:24,240 Here is the protocol. 791 00:43:24,240 --> 00:43:28,390 Suppose that Alice wants to send a message between Alice and Bob 792 00:43:28,390 --> 00:43:30,270 and we have our certificate authority. 793 00:43:30,270 --> 00:43:32,320 Alice says to the certificate authority, 794 00:43:32,320 --> 00:43:37,450 I would like to do some communication with Bob. 795 00:43:37,450 --> 00:43:39,020 And my name is Alice. 796 00:43:39,020 --> 00:43:46,160 What Bob sends back is one of these certificates, 797 00:43:46,160 --> 00:43:50,500 a signed message that has Alice's public key in it 798 00:43:50,500 --> 00:43:51,460 and Bob's public key. 799 00:43:51,460 --> 00:43:53,640 We call these signed messages certificates. 800 00:43:53,640 --> 00:43:55,550 These come from the certificate authority. 801 00:43:55,550 --> 00:43:58,570 And they basically are a way that if Alice trusts 802 00:43:58,570 --> 00:44:05,116 the certificate authority she can decode Bob's public key 803 00:44:05,116 --> 00:44:06,740 and be reasonably assured that this is, 804 00:44:06,740 --> 00:44:08,310 in fact, Bob's public key. 805 00:44:08,310 --> 00:44:13,220 She is also going to get a certificate for herself 806 00:44:13,220 --> 00:44:14,962 that she can send to Bob so that Bob 807 00:44:14,962 --> 00:44:17,420 doesn't have to go contact the certificate authority again. 808 00:44:17,420 --> 00:44:18,920 She is going to send this thing that 809 00:44:18,920 --> 00:44:21,260 has been signed the certificate authority which 810 00:44:21,260 --> 00:44:24,780 is going to allow Bob to authenticate her. 811 00:44:24,780 --> 00:44:27,530 So she does that. 812 00:44:27,530 --> 00:44:31,410 What she sends to Bob is her own certificate 813 00:44:31,410 --> 00:44:34,330 which is this little thing shown here on the left. 814 00:44:34,330 --> 00:44:46,350 And then she also sends to Bob a proposed shared key. 815 00:44:46,350 --> 00:44:47,100 This is kAB. 816 00:44:47,100 --> 00:44:50,310 And she signs that proposed key with her own private key. 817 00:44:50,310 --> 00:44:52,810 When she signs this key with her private key 818 00:44:52,810 --> 00:44:54,820 that means that Bob can be assured 819 00:44:54,820 --> 00:44:58,240 that this is an authentic message, in fact, from Alice. 820 00:44:58,240 --> 00:45:00,490 And then she encrypts it with Bob's public key 821 00:45:00,490 --> 00:45:06,830 so that only Bob can be the one who can decode it. 822 00:45:06,830 --> 00:45:10,750 So only Bob will actually see the contents, 823 00:45:10,750 --> 00:45:12,850 see what this key is. 824 00:45:12,850 --> 00:45:15,280 And these Ts that I have shown here are simply timestamps, 825 00:45:15,280 --> 00:45:16,240 and I will explain to you why those 826 00:45:16,240 --> 00:45:17,323 are important in a minute. 827 00:45:17,323 --> 00:45:20,520 We need timestamps that go along with these things. 828 00:45:20,520 --> 00:45:24,060 So this proposed key has been both signed 829 00:45:24,060 --> 00:45:25,640 with her private key and encrypted 830 00:45:25,640 --> 00:45:27,320 with Bob's public key. 831 00:45:27,320 --> 00:45:31,130 And now Bob can go ahead and send messages back to Alice. 832 00:45:31,130 --> 00:45:34,240 And he can encrypt those messages using kAB, 833 00:45:34,240 --> 00:45:38,170 using a shared key encryption mechanism which, as we said, 834 00:45:38,170 --> 00:45:39,060 is more efficient. 835 00:45:39,060 --> 00:45:41,314 So these guys can exchange a bunch of information 836 00:45:41,314 --> 00:45:42,480 with each other in this way. 837 00:45:48,280 --> 00:45:50,610 This is an example of a cryptographic protocol. 838 00:45:50,610 --> 00:45:51,760 I said there was a bug. 839 00:45:51,760 --> 00:45:53,540 Let's try and debug it a little bit. 840 00:45:53,540 --> 00:45:55,498 And, to get at that, let's talk about what some 841 00:45:55,498 --> 00:46:08,160 of the properties of cryptographic protocols 842 00:46:08,160 --> 00:46:09,820 that we would like. 843 00:46:09,820 --> 00:46:12,260 One property we would like is what is called freshness. 844 00:46:14,810 --> 00:46:17,360 What freshness means is that I am reasonably assured 845 00:46:17,360 --> 00:46:18,740 that this message is recent. 846 00:46:18,740 --> 00:46:21,040 It came from recent history. 847 00:46:21,040 --> 00:46:24,799 And this is what we need the timestamps for. 848 00:46:24,799 --> 00:46:27,340 We need to make sure that this message is, in fact, a message 849 00:46:27,340 --> 00:46:30,271 that is relatively new. 850 00:46:30,271 --> 00:46:32,770 It is not an old message that I generated before that is now 851 00:46:32,770 --> 00:46:35,120 being sent back to me again. 852 00:46:35,120 --> 00:46:38,340 That is what we are going to use the timestamps here for. 853 00:46:38,340 --> 00:46:41,170 We also want to make sure that the message is appropriate. 854 00:46:44,890 --> 00:46:51,460 And, by appropriate, I am actually the intended recipient 855 00:46:51,460 --> 00:46:54,260 of this message and the sender of this message 856 00:46:54,260 --> 00:46:57,710 is actually who the sender of this message claimed to be. 857 00:46:57,710 --> 00:47:00,750 This message actually should be applied right now. 858 00:47:00,750 --> 00:47:03,025 This message makes sense. 859 00:47:03,025 --> 00:47:04,900 And then, finally, the third property we want 860 00:47:04,900 --> 00:47:07,530 is something called forward secrecy. 861 00:47:07,530 --> 00:47:13,840 What this says is essentially we should 862 00:47:13,840 --> 00:47:15,840 be able to change the cryptographic keys that we 863 00:47:15,840 --> 00:47:17,600 are using at some point in the future. 864 00:47:17,600 --> 00:47:21,466 Say, for example, if our keys become compromised, we 865 00:47:21,466 --> 00:47:22,840 should be able to change the keys 866 00:47:22,840 --> 00:47:25,510 and our method should continue to work. 867 00:47:25,510 --> 00:47:29,590 This approach is pretty clearly true. 868 00:47:29,590 --> 00:47:32,700 Alice could request a new key. 869 00:47:32,700 --> 00:47:36,420 And then you could imagine some way in which Alice could 870 00:47:36,420 --> 00:47:38,920 create a new key and send that new key to Bob 871 00:47:38,920 --> 00:47:42,450 and we can sort of start all over again. 872 00:47:42,450 --> 00:47:44,450 The two properties that are really interesting 873 00:47:44,450 --> 00:47:47,190 are this freshness property and this appropriateness property, 874 00:47:47,190 --> 00:47:49,099 and they are the two properties that I 875 00:47:49,099 --> 00:47:50,640 want to talk about a little bit more. 876 00:47:50,640 --> 00:47:52,697 And if you think about what the kinds of attacks 877 00:47:52,697 --> 00:47:54,530 are that somebody could apply on this thing, 878 00:47:54,530 --> 00:47:55,920 well, one attack they could apply 879 00:47:55,920 --> 00:47:58,940 would be an attack on the sort of cryptographic 880 00:47:58,940 --> 00:48:00,080 transform itself. 881 00:48:00,080 --> 00:48:02,730 A brute force attack where you try and factor the keys, 882 00:48:02,730 --> 00:48:04,530 we said that is hard. 883 00:48:04,530 --> 00:48:07,120 Another attack that they could apply 884 00:48:07,120 --> 00:48:11,790 would be a so-called replay attack. 885 00:48:11,790 --> 00:48:17,350 There is a crypto attack and so-called replay attack. 886 00:48:20,770 --> 00:48:22,494 This is that somebody might sort of 887 00:48:22,494 --> 00:48:24,910 reuse a message that they saw transmitted over the network 888 00:48:24,910 --> 00:48:25,620 before. 889 00:48:25,620 --> 00:48:28,520 Some Eve or Lucifer might overhear a message 890 00:48:28,520 --> 00:48:30,834 and then might try and resend that message in order 891 00:48:30,834 --> 00:48:32,250 to get the server to do something. 892 00:48:32,250 --> 00:48:34,249 Suppose there is a message that tells the server 893 00:48:34,249 --> 00:48:37,740 to take some action in the outside world, open a door, 894 00:48:37,740 --> 00:48:40,880 so you might save up a message that somebody else had sent 895 00:48:40,880 --> 00:48:42,279 before that said open the door. 896 00:48:42,279 --> 00:48:43,820 And then you might resend it in order 897 00:48:43,820 --> 00:48:47,341 to get the door open when you wanted it to open. 898 00:48:47,341 --> 00:48:48,340 We want to prevent that. 899 00:48:48,340 --> 00:48:49,890 And we are going to use timestamps to do this. 900 00:48:49,890 --> 00:48:51,430 And getting the timestamps to work out 901 00:48:51,430 --> 00:48:52,420 is a little bit tricky. 902 00:48:52,420 --> 00:48:55,160 If the sender and the receiver have perfectly 903 00:48:55,160 --> 00:48:57,334 synchronized clocks, you might just 904 00:48:57,334 --> 00:48:59,500 say as long as the timestamp is within the first few 905 00:48:59,500 --> 00:49:01,100 milliseconds that is fine. 906 00:49:01,100 --> 00:49:03,000 But if that is not true then you need 907 00:49:03,000 --> 00:49:05,000 to do something a little bit more sophisticated. 908 00:49:05,000 --> 00:49:06,560 There is a protocol called Kerberos 909 00:49:06,560 --> 00:49:07,919 that works this out in detail. 910 00:49:07,919 --> 00:49:09,710 And that, again, is described in the notes. 911 00:49:09,710 --> 00:49:12,390 But the idea is just you put the timestamp in every message 912 00:49:12,390 --> 00:49:14,380 that you send. 913 00:49:14,380 --> 00:49:16,809 And then when you sign the message, when 914 00:49:16,809 --> 00:49:18,850 the person on the other end decodes that message, 915 00:49:18,850 --> 00:49:20,730 they know that this message was generated 916 00:49:20,730 --> 00:49:22,940 as of a particular time. 917 00:49:22,940 --> 00:49:25,730 But the third kind of attack we might be worried about 918 00:49:25,730 --> 00:49:31,180 is a so-called impersonation attack. 919 00:49:31,180 --> 00:49:34,750 And this is the attack that this protocol is susceptible to. 920 00:49:34,750 --> 00:49:45,490 Does anybody see what the bug in this protocol is? 921 00:49:53,807 --> 00:49:55,390 STUDENT: Charles does not authenticate 922 00:49:55,390 --> 00:49:57,490 that Alice is Alice. 923 00:49:57,490 --> 00:49:59,110 Charles does not authenticate? 924 00:49:59,110 --> 00:50:06,470 Well, Alice does send this key that says -- 925 00:50:06,470 --> 00:50:11,410 Charles doesn't actually care because all Charles saw was 926 00:50:11,410 --> 00:50:18,140 a message that said I want Alice's public key and B's 927 00:50:18,140 --> 00:50:19,650 public key. 928 00:50:19,650 --> 00:50:22,420 There is nothing wrong with that message getting corrupted. 929 00:50:22,420 --> 00:50:25,327 Alice might get something back, but if it comes back 930 00:50:25,327 --> 00:50:27,160 it has been signed with Charles' private key 931 00:50:27,160 --> 00:50:29,990 and so she will know exactly what it was that was in there. 932 00:50:29,990 --> 00:50:33,570 STUDENT: Only Alice knows Charles private key? 933 00:50:33,570 --> 00:50:37,590 I mean can't someone else impersonate Alice and do 934 00:50:37,590 --> 00:50:42,060 that whole process and then be seen as Alice by Bob? 935 00:50:42,060 --> 00:50:44,920 But notice that the key has been signed 936 00:50:44,920 --> 00:50:47,570 with Alice's private key. 937 00:50:47,570 --> 00:50:49,020 This proposed key has been signed 938 00:50:49,020 --> 00:50:50,520 with Alice's private key. 939 00:50:50,520 --> 00:50:54,940 STUDENT: Alice is sending something encoded in Charles' 940 00:50:54,940 --> 00:50:58,820 private key, is that right? 941 00:50:58,820 --> 00:50:59,320 No. 942 00:50:59,320 --> 00:51:01,160 Well, all this means is that the thing that 943 00:51:01,160 --> 00:51:03,660 is encoded with Charles' private key, Bob 944 00:51:03,660 --> 00:51:05,850 is going to be able to decode that thing using 945 00:51:05,850 --> 00:51:06,800 Charles' public key. 946 00:51:06,800 --> 00:51:08,425 And he is going to have some assurance, 947 00:51:08,425 --> 00:51:14,200 in fact, about what Alice's public key is. 948 00:51:14,200 --> 00:51:15,160 I think that is OK. 949 00:51:15,160 --> 00:51:17,540 Anybody else want to take a guess? 950 00:51:17,540 --> 00:51:18,040 OK. 951 00:51:18,040 --> 00:51:20,234 Well, since we are out of time, I 952 00:51:20,234 --> 00:51:22,150 will talk about this the first thing next time 953 00:51:22,150 --> 00:51:24,524 and will show you what the problem with this protocol is. 954 00:51:24,524 --> 00:51:26,320 I will see you on Monday. 955 00:51:26,320 --> 00:51:28,250 One announcement before you guys go. 956 00:51:28,250 --> 00:51:29,880 I have a little gift for you guys 957 00:51:29,880 --> 00:51:32,270 which is that we are going to cancel class next Wednesday 958 00:51:32,270 --> 00:51:34,201 before the design project is due. 959 00:51:34,201 --> 00:51:35,700 So there is no class next Wednesday, 960 00:51:35,700 --> 00:51:38,930 but there is class on Monday so make sure you come here.