OK, so today we're going to continue
our discussion of protection.
Remember, we have our three protection primitives
that we've been talking about, authentication, authorization
and confidentiality.
Today we're mostly going to focus on authorization
and confidentiality.
Remember, we have seen, and we are
going to continue to rely on this set
of cryptographic primitives.
So the cryptographic primitives that we talked about
are sign and verify.
And we said that sign accepts a message and some key.
And verify accepts the message and some k.
Sign accepts a message and a key and outputs some signature.
Verify accepts the message and the signature
and some other key k2 and tells us whether or not
it believes that the message that this m actually
corresponds to this signature.
And we talked about how if k1 is equal to k2
this is a shared key system.
And if k1 is not equal to k2 we typically
call this a public key system.
We also talked about our encrypt and decrypt primitives.
And we said that encrypt accepts some message m and some key k1
and outputs some encoded message C.
And decrypt takes C and some k2 and gives back m.
Again, we have the same separation between shared key
and public key, private key.
So, if you remember last time, we
were talking about this protocol that
was a protocol for establishing a secure communication channel.
We got as far as talking about how we would actually
authenticate a user.
We talked about the process for authentication.
And then we were using our authentication process
to build up a protocol for setting up
a secure communication channel.
The way this is going to work is that we
are going to use a public key cryptography.
We are going to use our encryption with a public key
to exchange a shared key.
And then we are going to use the shared key
to encrypt our communication.
We went through this example with the Denning-Sacco Protocol
which I will quickly review.
And, remember, I told you that this protocol is broken.
And we got as far as not quite figuring out how it was broken.
So let's see if we can figure out how it was broken.
Again, we said the idea is Alice first
sends a message to Charles.
And, remember in our model, Charles
is this certificate authority, the guy who both Alice
and Bob know and trust.
So Alice sends a message to Charles saying hey,
I would like to get these certificates for Alice and Bob
so that I can establish this clear communication channel.
Charles goes ahead and agrees with this
and sends a message back which consists of these two
certificates, one certificate for Alice
and one certificate for Bob.
Both of these certificates have been signed
with Charles' private key.
And because they are signed with Charles' private key
that presumably means that only Charles could have possibly
generated these certificates.
And there are two certificates, and each certificate
contains the name of the principle that the certificate
belongs to, the public key of that principle
and then some timestamp which, remember,
we said we want to use to make sure
that these certificates are fresh.
And now what happens is that Alice, in order
to establish this communication with Bob, needs to exchange
or needs to propose a shared key that she
can go ahead and use with Bob.
What she does is she sends her certificate,
which is something that Bob should
be able to use to validate that she is, in fact, who
she said she is.
And, remember, she cannot forget this because it's signed with
Charles' private key.
And she also goes ahead and sends this proposed key.
And the way she encodes the proposed key
is to sign it with her private key
so that Bob knows that it actually came from her.
And then she encrypts it with Bob's public key
so that only Bob can actually go ahead and decode this message.
Let's think for a minute.
We started to get towards figuring out what's
wrong with this protocol.
And the way that we started to talk about it
was, well, what properties would we like a protocol
like this to have?
We said one property we would like
is for it to have freshness.
What freshness means is that the protocol shouldn't be
susceptible to replay attacks.
That is somebody shouldn't be able to overhear a message
and then replay it sometime much later in order to sort of cause
that message to happen again.
So, even if that person cannot actually look inside
the contents of the message, they may be able to get
something to happen simply by replaying the message.
So freshness is something we want our protocols to have.
And, in this case, we are achieving freshness hopefully
by including this T which is a timestamp in the message.
As I said last time, getting the timestamp
to actually work correctly is something
that you have to be careful about.
And this is described in Section E of the notes.
The first property is freshness.
The second one is appropriateness.
That just means that this message is, in fact,
for the particular sender, it applies
for the particular sort of context in which
the message is being used.
So the people who are receiving the message, for example,
are actually the intended recipients of the message.
And then the third property we said
we want is forward secrecy.
And this just means that it will be
possible to switch to a new set of keys at some later time
if, for example, the keys get breached so we have
a way of changing the protocol.
This protocol that we have also achieves forward secrecy.
The problem it has is with appropriateness.
Let me show you what I mean by this protocol being
inappropriate.
Once we've exchanged this kAB now we can go ahead
and Bob and Alice can presumably communicate with each other
by encrypting messages to one another with this kAB key
that they've exchanged.
Let's see what the problem with this is.
Remember, Alice sends this message three to Bob.
Now here is what the issue is.
The issue has to do with this piece of information
that Alice has encrypted and signed.
And the problem is that this message does not satisfy
the appropriateness constraint.
In particular, it doesn't have any context
about which conversation this key is meant to apply to.
So let me show you a way in which Bob might exploit this.
Suppose Bob sends a message to Charles.
And what he sends in this message is I am Alice
and I would like to set up a conversation with you
and here is my public key and here is a bit of information
that I've signed using my private key that
is a key I would like to use for our conversation.
So Charles sees this thing and says oh, yes, Alice signed this
with her private key.
He can check with the certificate authority
and see that, in fact, this message
appears to be authentic.
And now he may go ahead and send a message
back to Bob that is signed with this kAB.
So Charles has been fooled into thinking
that Bob is, in fact, Alice and goes ahead
and starts to establish some communication with him.
Again, the issue is because this encrypted and signed thing
doesn't have any information about what conversation
this key is meant to apply to.
Alice hasn't said that this is only
a key that applies to a conversation between Alice
and Bob.
Now, anybody who overhears this can use this key
to establish a conversation that appears
to be originating with Alice that, in fact, is not.
Let me show you how we go ahead and fix this.
This is just exactly the protocol
that I showed you before.
And the way that we're going to fix this
is really pretty much as I've just described.
We are going to take this big nasty statement that we
had here, and we're going to basically sign and encrypt
the whole message instead of simply signing and encrypting
the one little piece of this message which was the proposed
key.
We are going to sign and encrypt the whole thing together,
including Alice's public key and Alice's certificate.
And we are also going to include a sender and receiver
in this entire message.
Now we said we add A and B as two
members of this entire message.
And what this allows us to do is to guaranty
that because Alice has signed this entire thing,
Bob isn't able to generate a new version of this thing,
or Bob isn't able to use this thing
to spoof a conversation with Charles.
Bob can go ahead and try and send this message for Charles,
but Charles could look at this thing
and obviously tell that this key was not
for a conversation between himself
and Alice but instead was for a conversation between Bob
and Alice.
And there is no way that Bob could
spoof the generation of this whole thing
because he doesn't have Alice's private key so he couldn't
sign this message.
That wraps up most of our discussion,
the extent of the discussion from last time.
What we saw last time basically is a way to do authentication,
and then at the very end we talk about how
we can use authentication to establish
the secure communications channel.
Establishing a secure communications channel
relies on sort of the confidentiality
piece of this story, and I just want
to spend a few minutes talking about what confidentiality is
and how it works.
Confidentiality, obviously, is the protection
of information exchange between two people or two principles,
say Alice and Bob.
And the idea is to make it so that somebody
who is overhearing this communication
wouldn't actually be able to tell
what the contents of the message that was overheard were.
The idea is suppose Alice generates some message m,
puts it into an encryption box, encrypts it with some key k1
and generates a new message C which gets
sent over the Internet to Bob.
On the other side, Bob feeds this thing
into a decryption box, decrypts it with k2 and gets m out.
And this has the properties that simply knowing C
makes it very hard to drive m.
Given C, driving m is very hard to do.
That is because of the difficulty of sort
of breaking these cryptographic protocols that we talked about
the first couple times, but given k2 and C
it is possible to drive m.
The only way that you can do this
is by applying some sort of attack
on the cryptographic mechanism hopefully.
But this property, given k2 you can derive C,
it is relatively easy for the receiver
to go ahead and figure out what the message is.
And since we are using these encrypt and decrypt boxes,
obviously, k1 could be equal to k2, in which case
we would be using a shared key approach.
And k1 and k2 can be different, in which case
we are using public key like we talked about.
What we did in the secure communication channel protocol
that we just talked about was to both authenticate and establish
confidentiality.
We had both confidentiality and authentication,
so at the end of this protocol Alice and Bob
have authenticated with each other
and they have confidentiality because they've
exchanged this key kAB that they can
use to have a private conversation with one another.
This is going to be a common thing
that we are going to want to be able to do,
confidentiality plus authentication.
And we see the way that we do that is
exactly the pattern that we have going on here in this example.
You take a message and you sign it and then you encrypt it.
So you have your message m.
It is signed with some key which we will call kconf
for confidentiality.
Sorry.
It is encrypted with kconf.
And then you're going to sign this whole thing
with some key kauth which is your key for authorization.
And it is OK, in this case, for these two things, this sign
and encrypt can be done in either order.
I can sign the message and then encrypt it or encrypt it
and then sign it.
It works out just fine.
This pattern is going to be a common one.
Often times, when we're building up
a secure system, what you want to do is first authenticate.
You want to both guaranty that the person you are talking to,
you want to know who the person you are talking to is,
and you also want the communication with that person
to be secure.
We talked at the beginning, when we first
starting talking about authentication
we talked about a simpler example
where you might just want to authenticate.
I had the example, suppose you're purchasing something
and you don't care if somebody knows that you purchase it,
like giving money to Save the Whales.
That example, you're giving money to save the whales.
All you care about is that Save the Whales can actually
authenticate your message, that the message is
well-formed from the point of view
that Save the Whales doesn't believe that you're giving them
$10,000 instead of a $100 and that Save the Whales knows
who you are so get credit for giving them that money,
but you don't actually maybe care
whether that message is encrypted.
Another common thing you are going to do
is just sign a message with kauth.
It is less common to see, well, the other thing you
might wonder is how often do people just
want confidentiality?
Just establishing confidentiality
is sort of less common.
You would see that less frequently.
Typically, people want to either do
confidentiality and authentication
or just authentication.
But just confidentiality is a little bit of a weird case
because having a private conversation with somebody
who you don't know there aren't that many cases where
you want it.
You could imagine an anonymous communication system,
for example, where you don't actually
want the other person to know anything about who you are.
But that's a little bit of an unusual situation.
These are kind of the two major forms of private communication
that we have talked about so far.
And we talked about a few little other details.
This example illustrated a few other little details
that we need to make sure we take care of.
One of them was this freshness constraint.
In this example, we said this is e.g., the addition
of T to this example up here.
So, when we add the timestamps, that
makes it difficult for somebody to apply a replay attack
against us.
The other thing that we might want to do is add T to m.
This is freshness.
This is going to add timestamp to m.
Now, the other thing we might want
is some way to guaranty appropriateness.
And, what we're going to do for appropriateness, what
we need to do to make sure the message
is appropriate is we need to add context to the message
so we need to add some information that
specifies who is originally involved in the message.
These are sort of the two major kinds of protection
that we have, and we need to make sure
that our protocols we use sort of
provide these kinds of guarantees.
Now what I want to do is talk a little bit about authorization.
We've seen authentication and a bit of confidentiality
and we've talked about authorization,
but I want to talk about it in the context of an example.
Because you guys know something about authorization techniques.
You guys have all seen, for example, passwords for logging
into a system.
There is no big surprise about how passwords work.
There is some list of passwords.
And, when a user tries to log in,
the system checks to see if the person is in the list.
They typically take the hash of the password that is typed in
and check to see if the hash of the password
is in the password list.
This is described in detail in the text
and we will go over it a little bit today,
but what I want to do is sort of talk about how we fit all three
of these things, authentication, authorization
and confidentiality together into one system
as we talk about authentication.
We are going to use an example.
Which is the Web.
Suppose that we were in a situation
where we have some browser B communicating
with some Web server W over a secure communication channel.
And, if you like, you can think of the secure communication
channel as having been established
by a protocol like the one I've shown here.
In practice on the Web, there is a common protocol
that is used to establish the secure communication channel
called SSL, secure sockets layer.
This channel has been authenticated
and is confidential.
It is typically the case, for example,
that there may be some certificate authority,
for example, which B has used to discover keys for W,
to discover a private key to use to talk to the Web server, W.
There is a question, though, that we haven't really
got at which is how does W know that B is authorized to access?
And we hinted at this on the first lecture about security,
but this is the question that we want to try and address
today in a little more detail.
The issue is that once this protocol is established,
these two guys have exchanged a key with each other, this kAB
or kBW.
And this is a shared key that these guys can
communicate with each other.
But basically all that W knows about B
is that this is somebody who has this key.
This is the same B who initiated this connection with me.
W may not have actually checked to go ahead and see
what it is on the server, what services on WB has access to.
So W needs to go ahead and figure out
what it is that B can access.
And these two sort of check all the accesses
that B tries to make on W to make sure
that it is authorized to do so.
If you remember back to the very first lecture,
we talked about how authentication
and authorization work.
We sort of said there are two steps.
Or, in this case, we are going to actually talk
about three steps.
We have three steps or let's call it three authorization
functions.
And these functions actually sort
of share something in common with authentication
because authenticating and authorizing
are sort of intertwined together.
You will see what I mean.
The first step is we need some rendezvous.
When we talk about this, this is the way
that two principles initially set up the access rights
to the particular server.
For example, this is you going to your system administrator
and telling your system administrator
that you would like an account.
He creates an account, he creates a home directly for you
and then you have the rights to access any of the files that
are in your home directly.
So think of rendezvous as setup.
Account creation, you can log onto Amazon dot com
and create an account, for example.
Then there is some other step which
is this verification step.
And verification is simply making sure
that when you reconnect to the system
you are allowed to connect to the things
that you want to connect to.
Typically, in an authorization system,
we talk about this thing mediating your communication
with the Web server.
If I log onto Amazon dot com and say
that I would like to log in as a particular user,
this verification step is going to make sure
that I have the appropriate credentials
to log on as that user.
The final thing I might want to do is to revoke.
I might want to simply remove a user from the system
or make it so that the user is no longer a part of the system.
There are two widely sort of used approaches
for authentication that sort of do different things
at these different steps.
The two approaches are called lists and tickets.
Authorization.
We have these two approaches.
The first one we are going to call lists and the second one
is called tickets.
And we have these three steps.
We have our setup step, we have our mediation step
and we have our revocation step.
Lists are something you may be familiar with.
One way that we might authorize whether or not
a user is allowed to access a system
is to check some list of all the users who are allowed access,
and we may check that user's credentials.
For example, if you go to a party
and that party is invite only and requires
you to show your MIT ID at the door, you show up at the door,
you show them your MIT ID and then that lets you in.
And now you've been sort of authorized to access the party.
The other approach is a ticket-based approach.
This is an approach where instead
of having a list of people and checking credentials
whenever the person wants access, instead
you have some ticket which lets anybody who
has that ticket have access.
This is a party is invitation only.
You get an invitation in the mail.
And now anybody who has that invitation
can go ahead and go to the party.
You guys are all familiar with systems
that work like that, baseball games,
carnival games or whatever it is.
You get tickets and you use those tickets
to get access to something.
And anybody who has those tickets can use them.
There is no checking of your sort of credentials every time
you try to use them.
As we're going to see, and we will
talk about how this works on the Web,
it is often the case that you use
one of these list-based authentication systems
to decide who we should issue tickets to.
And then you give a bunch of people tickets
and anybody can do whatever they want with those tickets.
Let's talk about sort of the properties of these things
and a little bit about how they work
in the context of a computer system.
The setup process and list is obviously
you add someone to a list.
Passwords typically are done with list-based systems.
The idea is when you add somebody to a password list
you input their name or their account name
and a cryptographic hash of the password that they typed in.
Usually, you want them to type the password in,
in some secure fashion.
You put the cryptographic hash of that password there.
And then, in order to mediate, in order to actually verify,
for example, that the password is going to be correct,
you are going to search the list and you
are going to verify that the password that they present,
in fact, hashes to the stored hash in the password file.
You are going to search the list and you're
going to also do this sort of check credentials step
and make sure the password is what it was supposed to be.
It is relatively easy then, in this environment,
to revoke somebody's access.
You can remove them from list.
And then, in that case, well, they
won't be able to use the system anymore.
Tickets.
The idea in a ticket-based system
is that you are going to generate a ticket.
And usually what that means in a computer system,
or the simplest way to generate a ticket in a computer system
is to make a sort of hard to guess number.
For example, this might be a hash of something
or it might just be a big random number.
You want it to be something that if somebody picks
another random number out of thin air
they don't have a very high probability of guessing
a number that actually allows them to access the system,
but anybody who has this ticket should
be able to access the system relatively easily.
Because these tickets are just, for example,
a big random number, users typically
should feel free to share these, might
be able to exchange these tickets with each other.
They should be able to share them with other people
and use them for access.
Whereas, users typically are not going to share their passwords
with other people.
Tickets are a way that a user can handoff
sort of the authority, the right to access
a system to some other user, they can delegate.
Now, to mediate we are just going to look up,
this is just going to be a table lookup.
We just need to make sure that this is a valid number that
was, in fact, given to us.
And, typically, we don't have to go and check credentials.
The user doesn't have to supply a password when they supply us
with a ticket.
And then, finally, in order to revoke,
well, we might be able to invalidate a ticket.
You might be able to say, for example, remove her
from the table.
That works fine if we're OK with getting rid
of an entire ticket.
But suppose, for example, that I want
to revoke the right of a single user to access the system.
That is very hard to do in a ticket-based system.
Suppose that you guys decide that you no longer want
me looking at some discussion board about 6.033
that you've set up.
And suppose because you're writing bad things about me
and you say, well, we don't want the professor
to be able to access this anymore.
So you try and revoke my access.
If you've been using a ticket-based system
that is going to be very hard unless you
invalidate that ticket.
And there are many people who are sharing the same ticket.
That's going to be hard to deny me access
because you're going to have to revoke that ticket
and then go to everybody else who might
be sharing that ticket and issue them a new one.
Whereas, in this sort of list-based system
you could have just removed my account.
This has an analogy in the real world.
For example, door locks are sort of like a ticket-based system.
You generate a physical key for something.
You could give that out to many people,
and then many people can have access to your house.
The problem is if you want to revoke access
to a single person then you have to sort of go and either
collect the keys from everybody, which may not be feasible,
or change the door locks which denies everybody
access until you reissue keys to the people who need them.
If you like, you can think of a ticket-based system
sort of like being door locks in a house.
Oftentimes lists are more formally called
ACLs or access control lists.
You will see this term used in the text, in fact, as well.
And tickets are sometimes called capabilities.
Capabilities are sort of the right
to access some resource on the computer that
can be delegated from one user to the other or one principle
to the other.
And, in practice, what we see both, as I said,
in the real world and in computer systems
is that we are often going to use
this list-based mechanisms to decide who to hand tickets out
to.
In the case of, OK, who are we going
to invite to our party, who are we
going to send invitations to in the mail,
well, you might have some list that you go ahead
and assemble based on either people
who you know to be MIT students or people who
meet some particular set of eligibility criteria.
That is the sort of process of checking a list.
And then, once you've assembled the list,
you are going to generate these tickets and send them out,
and then anybody can use those tickets.
This same analogy sort of holds true in the Internet,
so let's look at how we might build up an authorization
system on top of our secure channel between our browser
and our Web server.
We have our B talking over our secure channel of our Web
server.
And the idea is going to be as follows.
This Web server has some service that the user wants
to try and access, and we are going to have this guard.
Remember, we talked about this guard model before.
There is going to be some guard that
sits in front of this service that
is in charge of authorizing B to access this service.
And then there is some authorization module
that runs on B.
The idea is that B is going to initiate a connection
and then guard is going to send a message to the authorization
module on B saying who are you, what are your credentials
to access this system?
This is going to be a form of list-based access.
Now, this module on B is going to go ahead and send
a message back that says my name is, whatever my name is,
as well as some key, some credential like, for example,
a password that is their password for accessing
this system.
Notice that these two guys do not
need to worry about sort of protecting this channel, as
far as the rest of the Internet is already concerned,
because they have already established this secure channel
upon which they can do this exchange of information.
So they are hopefully not worried about other people
overhearing this message.
They may not need to protect this information that
is being transmitted in the same way
because they have already got the secure communication
channel that they have established at the lower
levels of this thing.
All of this communication is going
over this secure communication channel between these two guys.
This is a layer that is built on top
of this secure communication layer.
Now what happens is that what the guard is going to do
is look up this name and password, for example,
in some access control list and use
that to determine whether or not this person has
the rights to access and what they
have the rights to access to.
And he is going to generate for this person
a set of tickets that represent the sort of services
that this person can access on this system.
He is going to have some table of tickets,
and this table is going to have the ticket
number and the resource, for example, that the user is
allowed to access.
So he is going to send back some ticket number authNo back
to the user.
So we are going to add authNo.
And then maybe this gives him the right
to access some account, B's account information.
Now, with this authorization information,
this is the ticket.
Now every time that B wants to go ahead and access
his account, for example, he can read account B
and then he just passes the ticket.
And he can use this ticket over and over
and over again to access the account for as long
as the ticket is valid.
Often times there will be a timeout
associated with tickets.
But as long as the ticket is valid
he can go ahead and supply this ticket in order
to be able to access the resource that the ticket gives
him access to.
And he doesn't have to sort of re-authenticate himself.
He doesn't have to represent his credentials every time
he wants to access this resource on his account on the Web
server.
Are the HKN people here?
Yes.
OK.
We need to do HKN.
Why don't you just give me one more minute to wrap up and then
we can go ahead and do the HKN review.
This protocol, I mentioned that this is sort of like SSL,
or the SSL works in sort of this way.
On the Internet you may have heard about cookies.
Cookies on the Web are essentially a kind of ticket.
The idea with most cookie-based systems
is you log in with a password.
And then, when you log in with that password,
the system issues you a cookie.
And then when you want to re-access the system
you simply supply the cookie.
If you were to look at the contents
of a prototypical cookie, it would typically
have something like, for example,
the user's name and some timeout,
a valid period for the cookie, as well as
a hash of the user's name, that timeout and some,
for example, random number which is only known over here
at the service.
The service is going to protect this random number
and is going to hash it together with the user's
ID and this timeout.
And so now, when this cookie is supplied,
it is going to be hard for users to generate fake cookies,
but these cookies are going to allow the user
to go ahead and access the services on W without having
to re-authenticate every time.
And you can, in fact, in some cookie systems
share those cookies.
You could copy the cookie from one browser to another,
and you might be able to reuse that cookie
to access the system for as long as the cookie is valid.
Cookies typically timeout after an hour or two,
and so then you would have to re-authenticate
with the system.
That is all I wanted to really say about authentication.
What we are going to do is talk about some sort
of advanced protocols next time.
I want to remind you guys that there
is no class on this Wednesday so don't come here.
The next class is next Monday.
And that is it.
Good luck finishing your DP2 and have fun doing HKN reviews.