All right.
So just a couple of announcements real quick.
Can you guys turn this down a little bit?
So, for tomorrow, you guys should all
be ready to give these short presentations on your design
projects in recitation.
We posted a one-page guide talking
about what it is that you should prepare for next time in class.
These are short presentation.
You shouldn't need to put too much time into getting them
together, but please look at the Web page
if you're not sure of what it is that you're
supposed to be doing in class.
Today what we're going to do is wrap up
our discussion of security.
And what I want to do is start off
with a fun little diversion which
is over the past couple of times that you guys were in class
we captured a log of all of the network traffic
that was going on while people were in class on their laptops.
And, for the most part, it turned out
that you guys were pretty boring.
Nobody was actually doing anything exciting,
but there were a couple of interesting lessons.
In case you're curious as to what we actually did,
we ran this TCP dump command.
The pseudo command just says run this command
as though you are a super user, as though you are SU.
And then TCP dump just says dump out all the traffic
on the specific network interface.
In this case, it is dumping out all the traffic
on EN1 which on this computer is the wireless network.
So we are just dumping out all of the packets that
were sent out over EM1.
And what you see here is the yellow part
is the sort of header of the packet saying this is an IP
packet and specifying who the destination and recipient
of this packet are.
And then there is some body text, some sort of payload that
is associated with this packet.
In this case, this first packet is some binary data.
We cannot make any sense of it, but if you look at some
of these other packets, for example,
this is a packet which is an HTTP request packet.
What you see is that there, in fact, is English text.
The HTTP protocol uses English text to transmit information,
and so this is specifying some information
about this is the actual HTTP request going out.
In this case, it was going out from this laptop.
I just set this up as to illustrate what TCP dump does.
We ran a command like this while you guys where in class
and captured a trace of what you were doing.
And we ran a little Perl script that
went through this trace of packets
and sucked out all the Web pages that you guys
had been looking at.
And so I have pictures of some of the Web pages.
A lot of it, as I said, is pretty boring.
There is somebody who is looking to buy a micro drive so they
searched for Micro Center cruiser USB high-speed
on Google.
We saw this page coming back from Google
which was the search request.
And, in fact, you sort of poke around some more
and see this person actually found the Micro Center Website
and went to Micro Center and apparently
was trying to purchase this thing.
There were also a couple of people
looking for movies, people who were looking for a movie
to see.
In fact, we actually saw this on both days.
It wasn't just one day that somebody
was looking for movies, but somebody keeps coming to class
and looking for movies.
The next one, though, is much more interesting.
There are a couple of Web pages where
somebody is looking at a tool called Gaim-Encryption.
Gaim is the open source AOL Instant Messenger client,
and Gaim-Encryption is a version of the open source Gaim
client that encrypts data that gets
transmitted over the network.
And the way it works is when you install this tool it generates
you a public/private key pair.
And then, when you have a chat session with somebody
else who is also using this Gaim-Encryption tool,
it sends that person your public key
and then it uses public/private key encryption and signing
in order to protect information that gets transmitted
over the network.
So there was somebody who, during class,
was looking at this tool.
We see they go to the project page, sourceforge,
where this tool is hosted.
And they are clicking around looking at what the tool does
and reading about it.
And then you see that they download this tool.
And, in fact, after that, at some point,
there is a whole lot of AOL Instant Messenger traffic
that is going out on the network.
I am just surmising that this traffic actually
belongs to this person who downloaded this tool.
And you can see that, in fact, the tool appears to be working.
So this traffic is not intelligible.
And, in other cases, when you see this tool actually
goes across the network in plain text,
the Gaim normally runs in plain text
and you can just see the entire transcript of the chat
happening if you run this tool.
There is a very interesting security lesson here
which is that sometime later, in this particular trace
of a chat, we see this same person.
Person one, their name is transmitted in plain text.
You see this same person even when using the Gaim tool.
You don't see their messages in plain text,
but you see this person now actually
is talking, having a conversation.
And they sort of say oh, I download this Gaim tool,
now I can talk encrypted to other people.
And yet there is this conversation
where it is not encrypted, and this sort of dialogue goes on.
They are talking about somebody who is in class
and say why doesn't this person go to class anymore?
And they are having this little chat session back and forth
about why this person isn't in class.
And the dialogue goes on talking about their design project
and they're worried about it.
It is sort of a nice example of a security
problem or a potential security problem,
which is that this person actually did something
that was sort of nice.
They came to security class, they
are learning about security in class,
they go download this tool and think,
OK, I've got this tool installed and now my conversations
are protected.
And then, as soon as they try and talk
to somebody who isn't also running
this version of the tool, their conversations
are no longer protected anymore.
This is sort of a nice example of why security is actually
a really hard thing to get right.
Because this person may have even believed
that this person they were talking
to had this tool installed as well,
but you sort of don't know that it is not working
until somebody points out that it is not working,
somebody violates, goes in and is
able to access this on unprotected data.
This is a nice example of why security is hard
and why sort of providing protection
is essentially a negative role.
You never really know that you are
protected until somebody points out that you are not protected.
That was sort of a little lesson about security,
and I hope that it sort of pointing out a reason in which
why it is that security is something
that is both difficult and something that you
might want to be conscious of.
Often times when you're sitting there using your laptop,
you have this perception that is my information I am sending,
nobody is going to be able to overhear this information.
It is going so fast and being transmitted so instantly
that, of course, I am private.
You feel very sort of isolated when
you're having this communication until somebody points out
that it is actually very easy, I mean
this is a tool that is standard on all Linux distributions.
And it is one line that we type into our computer
to get this information.
It is actually very easy to do this,
so it is something that when you are transmitting
sensitive information out over the network over an email
or in an Instant Messenger you might want to actually think
about whether or not you want to be sending
this information out in the way that you're sending it out.
What I want to do now is come back to something we were
talking about last time, finish up our discussion a little bit
of authorization and then talk about how we can start thinking
about designing protocols that actually provide --
How we can reason about these security
protocols that we are using.
In particular, how we can reason about authentication protocols
within networks.
If you remember last time, we talked
about this idea of building up a secure communication channel
and then we talked about doing authorization
on top of that channel.
Remember, authorization is this process
of determining whether a given user should have access
to a particular resource that they want access to.
We talked about two main techniques
for doing this, ACLs and tickets.
An ACL is an access control list which
is just a list of users who are authorized to access
a particular resource.
And so the way typically an access
control list works is that the system first authenticates
the user to determine what their identify is
and then it checks to see whether that identity is
actually on this access control list
and the user is authorized to access this particular resource
they want access to.
Now, ticket has a slightly different flavor
which is typically if a user presents
a ticket you do not need to actually check and see
what their identity is.
Simply having the ticket is sufficient to allow somebody
to have access to a resource.
The analogy here is very similar to a physical ticket
in the real world.
You go to a concert, you hand them a ticket
and they let you into the concert
without checking your ID.
A common example of a ticket in the real world
is on the Web you get these cookies which are like tickets.
And the reason you use cookies instead
of checking access control list every time is
that when you have a particular cookie
the system doesn't have to re-authenticate you in order
to allow you to have access to the system every time
you revisit a page.
I have a cookie for Amazon dot com
on my computer when I am in the process of purchasing
some item from Amazon dot com that identified
my identity and my shopping cart and I
don't have to sort of re-log in every time I request
a new secure page from Amazon.
Specifically, what we are talking about is the Web.
And we had a browser and a Web server.
And the browser and the Web server
were talking over one of these secure communication channels.
And we said this channel has both been authenticated
and is confidential.
Authorization, we said, happens where there is
some guard process in charge.
This is our guard.
And it sits in front of the services on the system.
When a request comes in to access a service,
the Web server passes that request
onto the guard module which does the authorization.
And then, if the request is authorized,
it goes ahead and passes it onto the service.
We talked about this notion of how we establish
a secure communication channel.
Typically, we do that by exchanging,
one way that we talk about doing this is where B, for example,
would discover W's public key somehow and then use
that public key in order to exchange with W a shared
secret key that they could use to encrypt
all their communication.
I will show that protocol again in a minute, but the question,
and the question that we are really going to get at today,
we want to focus in more on this question of how
it is that B actually discovers W's
public key in a public key system
and how it is that B can convince itself
that, in fact, it is actually talking with this service W.
If B wants to have a conversation with Amazon dot
com, how does it actually convince itself
that this public key that it has, in fact, belongs to Amazon
dot com and that it is actually having
a conversation with Amazon dot com instead of with somebody
else who is pretending to be Amazon
dot com or has lied about Amazon dot com's public key
so that it can overhear Amazon dot com's traffic.
We are going to focus in more on that now.
Let's look at this simplified version of an authentication
protocol.
This is going to be like the Denning-Sacco Protocol
that I showed with the broken example
or like SSL, for example, on the Internet also sort of works
roughly in this way.
We've got our browser, we've got our Web server
and we've got some certificate authority.
This is the kind of picture we drew before.
We said the browser sends to the certificate authority
a request for, say, the public key of W.
The certificate authority sends a message back
with has the certificate for B and the certificate for W.
And these are simply signed things
that the certificate authority has
signed that include the public key for B and W in them,
so that is all certificates are.
And then B sends a message to W.
And there is some trickiness in getting this message right,
but this message basically is a signed and encrypted message
that tells W that it would like to initiate
a conversation with it.
And perhaps it proposes a shared key
that it can use in that conversation.
It is a little bit tricky to actually figure out and make
sure we get the format of that message right,
and that was there is bug with the Denning-Sacco Protocol,
but you get the idea.
So W then sends a message back saying perhaps asking user
to go ahead and trying to authorize the user saying,
OK, I agree that that is the key, now what is your name
and what is your password, for example.
And then, once it has exchanged that name and password,
B is allowed to log into the system and access whatever
these resources B should have access to on the server.
The question that I want to focus on
is this question about how B actually
decides the certificate authority that it should trust.
How does B initially establish the sort of authenticity
of the certificate authority?
When we talked about authentication
before, we presented this model that was sort of, well,
you are going to decide that you trust somebody by, for example,
having a conversation with the.
I am going to run into you in the hall
and you're going to say my public key is X,
and then I am going to be able to have
a conversation with you.
But, clearly, that is not what happens
in the case of the Internet.
For example, on the Internet, I do not
have to call up Amazon dot com or call up my certificate
authority and get the certificate authority's
public key from them.
Somehow I have already gotten this thing.
And so we sort of want to think about how
it is that we can actually exchange these keys
and how it is that these systems can actually decide that they
trust each other and that they are willing to authenticate
each other.
To do that, what we are going to do
is look at something called authentication logic.
The specific version of authentication logic
we are going to talk about is something called BAN logic.
B, A and N just stand for the names of the three people
who proposed this thing so it is not a specific acronym you
need to know.
And so what authentication logic is going to do
is allow us to reason about these protocols
for deciding whether or not we actually
trust something like a given certificate authority.
Just to think about this a little bit more,
let's look at a specific example.
Suppose that you receive a message over the Internet.
Suppose this message says it is some message m
and the message says sign is signed m with some key k,
call it k sub A.
And suppose that the contents of message m are m
equals give A your credit card number.
This might be a valid request.
We might be purchasing something from Amazon dot com.
In that case, you might think it might be OK,
we might expect to receive a request like this.
So this thing was signed with kA and the message
said give A your credit card number,
but how do we actually know, you know, maybe A, in this case,
is give to Amazon dot com and we know that we
are talking to Amazon dot com.
And so if this, in fact, were an authentic message,
we might be actually willing to give Amazon our credit card
number.
How do we actually know, though, that this message,
that kA is the key that belongs to Amazon dot com?
We want to answer the question how do we
know that or trust that kA, we are going to say, speaks for A?
This notation speaks for just means
that if we see something that, for example, is signed with kA
that claims to be from A, we might actually trust, in fact,
that this thing came from A.
And we want to sort of determine,
we are going to try and answer the question of how
do we trust this?
One way that we might trust this is true is if we had heard,
for example, some message, let's call it m2 -- --
from somebody B that had said that --
Or this message said kA is A's key.
One way that we might start thinking about, one way that we
might trust A is if we had heard from somebody else
or heard from some other place that kA was A's key.
But now this is kind of a slippery slope
because now you say the question, well,
how did you determine that you trust B's key?
There is sort of this infinite process
that you could end up going through.
And that doesn't sound like a very good idea.
One way in which sort of we might
bottom out this recursion, we might
end this sort of infinite process of collecting
keys is if we actually sort of, in the example I gave you,
heard from one person at some point
suppose there is a B and a C and D and E and an F.
And then eventually we get to F.
F is our friend who we had talked to,
and F had said my public key is this and here is
the public keys for a few people that I know.
So you might trust F and you might
believe that F knows a few other people.
And then those people who F knows
might in turn know a few other people.
And eventually we might be able to sort of
have this web of inner connected people all of whom we trust.
So this would be sort of a "web of trust".
We might be able to build up a web of trust like this,
but you could imagine that these relationships are
pretty complicated.
For example, B might trust a few people
and C might trust a few people and D might trust a few people.
And, every time we're presented with some message,
we need to have some sort of principled way of thinking
about whether we have a set of these keys,
for example, that actually allow us
to decide whether we should accept this message
or believe this message or not.
If we had a web of trust like this,
we would need some way of going about validating or verifying
that, in fact, these messages were messages we should trust.
That is what authentication logic is really all about.
This is the simplified band logic
that is presented in the text.
It is on page 11-85.
If you want to copy it down, I will try and leave
time for you, but in case you want to just copy it out
of the text you might not need to worry about copying down
the exact logic here.
There are three rules in this simplified authentication logic
and they use this notation, this speaks for notation,
and they are also going to use some notation that
says notation.
What this rule says is if A says B speaks
for A then B speaks for A.
So this sounds like sort of an obvious statement.
Saying that A says something means
that if we hear A say something that
means that A told us and we believed that this, in fact,
was A who told us this thing.
So, in order for A to say something,
we have to actually believe this cannot be a message,
for example, that we received over an untrusted network.
This has to be I sat next to A in the hall
and A actually said B speaks for me.
In this case, B might be, for example, some key.
So A might say my public key is kA.
If that is true and, in fact, we believe
that A is the person who said this to us then
we might be able to infer from that
that this key kA actually speaks for A.
This is what the first rule is and this
is the base case of you have a trusted communication
channel with communicating with A
and you can use that trusted communication
channel to actually build up some belief about, for example,
a key representing somebody.
Now, the next rule is one that sort of says
given that we have some belief about one of these things
like, for example, if we know that B speaks for A,
we know what A's public key is and we
overhear B saying that A says X then we might believe,
in fact, that A says X.
A simple example of this is suppose
we get a message that has been signed by this key kA.
If we see that then we might, in fact, believe that kA actually
says that A says m.
And we might believe that kA says this
because we believe that this sort of sign primitive
actually means that if we see something that
was signed with kA's key that, in fact, that thing was
generated by kA.
Nobody else could have generated a signed message
that worked with kA.
We can actually now receive a message from A
that has been signed using kA and we can, in fact,
believe that A said something.
Now, the final rule that we have is
sort of a transitivity rule which
is a way of expanding this web of who is related to whom.
This says if B speaks for A and A speaks for C then what
we're going to believe is that B speaks for C.
This is just a transitive relationship.
For example, if we know that kA speaks for A
and we definitely overhear B saying A speaks for B,
if B delegates and says that A can speak for me then we
might believe that key kA also speaks for B.
This is a simple transitivity relationship.
The idea with these rules is that we
are going to be able to apply these rules any time we have
a conversation to decide, again, whether we actually
trust the people who we are communicating with.
And you may have noticed, when I was talking about this,
that there were a lot of statements
like nobody can actually fake this protocol sign X.
We believe that nobody could forge this message that
was signed with kA for example.
If we believe that that is true then we can say kA
says this thing.
This authentication logic is full of a lot
of these sort of like if we believe
this thing is true kinds of assumptions
that we are going to be making.
My example was kind of confusing.
In this example, B is actually C.
kA is B.
It says if we know that A speaks for B
then we might be willing to believe that kA actually
speaks for B, given that kA speaks for A.
So we have this transitivity kind of a relationship.
Sorry that the notation was a little bit confusing.
I agree.
The challenge here is that we want
to try and make, any time we're using this authentication
logic, in order to actually determine
that somebody definitely said something
we are going to have to make some set of assumptions
about what we trust and what we believe.
And one of the things that is important,
any time you are using this authentication logic,
is to actually make these assumptions as explicit
as you can.
Let's look at a set of assumptions
that we are making here.
I said something like when I see a message that says sign m, kA.
And then I infer from that that A says m,
assuming that I already know that kA speaks for A, if I have
something like this and I make this inference that A
says m given that kA speaks for A then that's all a sign thing.
I am making a set of assumptions when I do this.
I am making a set of assumption, in particular, about what
this sign protocol does.
I am assuming, for example, that sign is actually
secure in some way.
I am assuming that this signature is not forgeable,
that somebody else could not have generated
a signature unless they actually had access, for example,
to the private key or to the private key of A.
This signature is not forgeable.
I am also assuming, for example, that any private keys
are actually private.
I am assuming that, for example, A hasn't gone out
and broadcasted the private key to everybody else in the world.
Because if A had done that then I wouldn't actually
know that A actually said m.
It could have been anybody who said m.
I would be in trouble if that were the case.
Any time that I sort of take this and make this inference
from seeing a sign like this then that
suggests that I am sort of making these two assumptions.
And it is not that these assumptions are wrong or bad,
it is just that it is good to think about exclusively what
they are.
Assuming that the signature is forgeable well,
we all know that cryptography can sometimes be broken.
It is not that cryptography is totally foolproof,
but we may have a relatively high confidence
that this cryptography is going to be difficult for somebody
to break.
And, while assuming that private keys are actually private,
we might sort of know A personally
and believe that A is outright upstanding individual
and we are going to trust that she hasn't
gone and disseminated her key everywhere around the world
because that wouldn't really be in her interest
and we take her to be a trustworthy person.
This is a bit of a leap of faith that we are making about this.
But if we believe those two things then
we can, in fact, infer that A says
m when we see a message that is signed with kA.
Let's look at another example that
works with this sort of public key cryptography
that we talked about in this example
with this authentication protocol here.
Suppose that A tells me my public key is kA pub
and this is done over a secure communication
channel like in-person communication,
I might then infer that kA pub actually speaks for A.
Now, suppose I see a message that
has been signed with kA private, I might say,
and this is an inference, that kA private says that A says m.
The question we want to ask now is should we actually
believe that A said m?
I saw a message, I know what A's public key is
and I trust A's public key maybe and I saw this sign thing.
Now I need to think about do I believe now
that A actually said m given that I saw a message that
was signed with kA private?
There is something obviously that we
need to do which is that we need to verify this message.
Suppose we go and we run this verify step
on this message and this verify comes out to be true.
I verify using kA pub that, in fact, this message
was appropriately signed.
Verify says yes, the signature on this message checks.
Now should I believe that that A actually said m?
That depends.
There are a couple of conditions,
again, sort of set of assumptions that we are making.
One thing we are clearly doing is assuming that this crypto
system is secure.
We are also believing that this verification step actually
gives us, that by taking something that has been signed
with a private key and then verifying it
with the public key that that is as good as A
actually saying something.
One thing clearly that depends on
is that the crypto system is secure.
There are a couple of other assumptions that we are making.
One thing is that it definitely, again,
requires that kA private has actually been kept secret.
And, furthermore, it requires that A didn't lie
to us about what kA public was.
Because if A had given us a wrong kA public
then somebody else could have signed this message
and then we might try and verify the message
using the lied about kA public and then we
might be in trouble.
Again, this is similar to this example with just kA
but just showing how it works with public and private
key encryption.
It is this case that, again, we sort of need
to always think about making our assumptions
as explicit as possible.
And that is really what it's about.
Deciding that we trust, for example,
the signature is true is analogous to deciding
that we have to sort of trust that we trust the cryptography.
It is possible to apply this authentication logic
in other environments as well that aren't necessarily based
on cryptography.
For example, instead of trusting that the cryptographic system
works, I might trust that a particular communication
channel is secure.
For example, if I pick up the telephone
and call you and give you some message,
you might trust that it's me because, for example, you
believe that it wouldn't be possible for somebody
to fake my voice.
And you recognize my voice because you've
come to lecture so many times.
That would be an example of a way in which you might decide
that you trust that something is actually true,
and that would be an assumption that you're
making about somebody not being able to fake my voice.
The point of authentication logic
is that it gives us a way to kind
of reason about these kinds of deductions about
whether or not we actually believe that somebody
said something was true or not.
That is fine.
We still, though, at least when we're
using public and private key cryptography,
haven't exactly answered the question
of how we go about establishing this initial trust step.
We said we might establish initial trust by --
At the bottom of this is we have to actually physically
overhear somebody say something over a secure communication
channel, we think.
We have to have some way to getting this first rule where
A says that my, for example, public key is something
so we can learn A's public key so that then we can bootstrap
communication with A.
We haven't yet answered the question of how we actually
exchange these keys except for by this one method
that we talked about, this web of trust method.
There is this question about establishing
some initial trust.
One way we might do this is using
this web of trust approach where I meet a friend,
that friend tells me about some people who he or she trusts,
and then those friends' friends' in term know a few people
and eventually we establish communication with everybody.
There are some computer systems that work this way.
In particular, there is a system called
PGP for pretty good privacy which
is an email-based privacy encryption
system that works this way.
And there are, in fact, websites where sort of the idea
is you find somebody else who has used this system,
you share and you exchange public keys with them
and then, once you have a few public keys,
you can sort of build out this web of trust to everybody else
by trusting people who your friends trust.
The problem is, one, clearly the Internet doesn't work this way
so you don't have this kind of system
that you're using on the Internet
and, two, these kinds of systems are
very difficult to set up and maintain
and there ends up being some centralized administration.
You end up with having to have some sort of way,
it becomes very difficult to actually discriminate
these kinds of public keys in these kinds of systems.
The way this works is there is a centralized website.
There is a website for PGP that is a giant database of keys
and you sort of try and discover people's keys
by locking this web of trust, but it
tends to be difficult to use.
Let's talk a little bit about how this actually works
in the context of the Internet.
Suppose there is actually some person, P,
who is sitting in front of this browser,
and there are some questions that we might
want to ask when we're thinking about deciding whether or not
we trust this person, P. One question
that the Web server might ask is does W know or trust person P,
or how does it?
This is a commercial website like Amazon dot com.
Actually, the trust story turns out to not be that complicated.
Amazon dot com doesn't really care
that you are who you claim to be,
as long as you give them the money that they want.
You can go on and tell them that you are Oscar the Grouch,
they don't care, as long as you give them
the money that they want for whatever it is that you order.
That is all that matters to them.
So, in fact, what Amazon does is they don't actually
know who you are exactly but they might decide that they
trust you because the credit card number is good
and is verified by the credit card company.
When they try and charge your credit card they get the money
and they are happy.
And there is this other question, though,
about how does P trust W?
And the way that this works on the Internet
is basically like the way that this authentication
protocol that I have shown you here works,
this is how SSL works.
And it turns out to be very subtle.
It can be quite hard to actually convince yourself
that you should trust a given website if you actually
start grilling down on it.
The way that it is going to decide that it trusts W
is by checking with some certificate authority.
That is how it works on the Internet.
And there are some issues with it,
which is how does the certificate
authority authenticate W?
How does the certificate authority
decide what W's key was and how do they securely exchange keys?
How did the user get the CA's public key?
And then what if somebody's private keys are stolen?
For example, W or the certificate authority's
private keys are stolen.
What I want to do is just sort of show you,
at a high level, how this actually works on the Internet.
I thought it might be instructive just
to see an example of what is actually going on,
on the Internet, and to kind of illustrate
how some of these issues are and are not properly
addressed by the current sort of SSL-based Internet
architecture.
I have a couple of websites open here.
I have an Amazon dot com website and I
have, in this case, an Apple developer website,
both of which you will notice have HTTPS URLs associated
with them.
In this browser, if I click on this little secure icon here,
almost any browser would have a similar sort
of feature, a little lock somewhere that when
you are viewing an HTTPS page.
What I see is something that lists
how it was that this site actually
decided that this was a secure site that it should communicate
with.
When that little lock appears it means
that my browser has actually decided
that it trusts this site.
We are at the point where we have already
said we trust this site.
And the reason that we trust this site, it says,
is because this site is WWW dot Amazon dot com
and we have this certificate for this site that
was issued by RSA Data Security Incorporated.
You might say who is RSA Data Security Incorporated?
I have never heard of these people.
I have never exchanged any information with them.
But they are the certificate authority.
That is the person who signed this thing.
I can look and sort of drill down on this.
And what you will see is some information
about Amazon dot com.
This is the actual certificate itself.
This is some information about the certificate authority,
including information about what algorithm
the certificate authority has used
to generate this certificate.
And then now what we have is this public key information,
the actual public key that corresponds to Amazon dot com.
The certificate contains Amazon dot
com's public key that was encrypted
using the RSA algorithm.
And then there also is some information, this signature
that goes with this public key.
This is the signature that was signed by this RSA corporation.
If I go to a different site like, for example,
this Apple site over here, we see
that this thing was actually signed by somebody else.
This certificate is signed by somebody
called VeriSign Incorporated.
Again, you have no idea who VeriSign Incorporated is,
but you will notice that these are two different certificate
authorities.
It is not the case that there is one master certificate
authority out there on the Internet that
is in charge of everything.
On a Mac anyway, the same is true of most other operating
systems, there is a way that we can
go and look at the actual list of all the people
who we trust are.
This is sort of an instructive thing to do.
To go and see who it is that you actually trust that
is on this computer.
I can click on this certificate over here.
This is a list of all the certificates on this machine
that I have and where I would accept things from.
You can see there are a very large number of certificates
that this machine has installed.
These are not just certificates but actual certificate
authorities.
People who I would actually trust
to sign a communication with a given site to provide me
with a certificate for, say, some Web server
that I want to communicate with.
Now the question is so where did these things come from?
They came from one of two places.
Either I added them to the system myself.
In this case, I have, for example,
an MIT certification authority.
If any of you have ever used MIT certificates
like when you're logging onto Websys,
in order to be able to access that system
you had to add support for a given
certificate to your browser.
This MIT certification authority is a certificate
that came from MIT and this keychain thing
which shows me on my certificates
has this funny sort of message that
says this certificate is not in the trusted root database.
The reason it says that is, this is a certificate for the MIT
certification authority, I just got this certificate
for the certification authority off the Web somewhere.
And I didn't do something that it
wanted me to do to actually verify that this, in fact, was
a legitimate certificate from the certificate authority.
Somebody could have put this thing on the Web
and said this is a certificate for the MIT certificate
authority and you should use it to discover certificates
for anybody who claims to be coming from MIT dot edu.
They could have lied about it and then I would be in trouble.
It is possible that this is a fake certificate for the MIT
certificate authority, but I sort of
have made this trust, this assumption that it is not
because I downloaded it from a website.
And I believe that, in fact, this is a valid certificate.
The other things you see here are this large number
of certificates.
For example, one of the ones that we see,
let's see if we can find RSA here, this RSA security.
Here I see RSA security.
And this thing actually says this certificate is valid.
Now there is this question about where
did RSA security come from?
And the way that this works is that this browser
and, in this case, the operating system
itself has actually been shipped with a bunch of certificates
from a bunch of different certificate authorities.
And so these have been installed by the operating system
manufacturer.
And I am saying I trust Apple to have
gotten the appropriate certificates
and loaded them appropriately into the computer.
And any time you download a browser basically
that browser already has a set of certificates
for a set of certificate authorities
already installed in it.
And that is where all of these base certificate authorities
come from.
You can see that when you are using one of these things
you have already placed quite a bit of trust
and made a number of assumptions about who you trust
and what you should trust just by using this system.
We have answered this question now
about where did the user get the public key for the certificate
authority?
Either they explicitly added it by downloading it
from a website, for example, or it came with the browser.
What about this question how does the certificate authority
authenticate an actual website?
How does Amazon dot com get a certificate from VeriSign?
The answer to this turns out to be
that Amazon dot com probably paid VeriSign some money.
And it is not even clear you can say that,
but in the case of VeriSign you are probably
pretty sure that Amazon dot com paid them some money.
And you can probably go to the VeriSign website
and see a list of things that they
claimed to have done in sort of authenticating Amazon dot com.
They may have forced Amazon dot com
to present them with some information that actually
suggests that they are the company Amazon dot com
or they own some right to the name Amazon dot com
or that they are incorporated under the name Amazon dot com.
Basically, the certificate authority
has some protocol that it uses to authenticate W.
And we don't know what that protocol is,
but you're sort of implicitly trusting
that all these certificate authorities that Apple has
already approved for you, in fact,
use some process that we will be reasonably assured
of guarantying your privacy or guarantying
that the websites that you are connecting to
are, in fact, valid websites that you
should feel comfortable giving your credit card number to.
You can see that this is a little bit dicey.
If feels a little bit like it is not clear
that this is incredibly secure.
And then the last question is well,
what if your private keys are stolen?
If your private keys are stolen in this particular example,
the certificates that you have from Amazon dot com,
if Amazon dot com's private keys are stolen
and one of the certificate authority's private keys
are stolen then you are in trouble.
These certificates typically have expiration dates
associated with them, but these expiration dates
are often like a year or more into the future.
And so you are going to continue to trust that certificate
until this certificate expires in the future when you
will go try and get a new one.
For that whole time that you trust that certificate somebody
who had access to the private keys from that certificate
authority or from that website would
be able to pretend to be that certificate
authority or that website.
So that might be problematic.
That is sort of the end of this little discussion about how
certificate authorities work.
I hope you can see that this authentication logic is sort
of a way that we can start to get at thinking about what
the trust assumptions that we are making
are when we are using these systems.
This wraps up our discussion of security.
We have one class session last.
And the last class session is actually
going to be a guest lecturer.
It is going to be somebody talking
about how law and computers and technology interact
with each other.
We are kind of step back and talk
much more about high-level pictures like policy and law
next time, and hopefully it will give you a good wrap-up
for the whole class of 6.033.
We will see you next time.
Please come to class because there
will be questions on the guest lecturer on the exam,
so you want to make sure you don't miss it.