Just one brief announcement.
HKN reviews are going to be done in class next Monday
so you guys should make sure you come, give us your feedback,
let us know what you like and what you don't like.
And, with that, we'll start talking about protection.
Protection is like fault-tolerance
and recoverability.
One of these properties of systems,
or building secure and protected systems
has implications for the entire design of the system.
And it's going to be sort of a set of cross-cutting issues
that is going to affect the way that, for example,
the networking protocols are designed
or that the sort of modules that make up your biggest computer
system are designs.
So it's going to be a whole set of usually
that we're going to look at through the course
of this discussion about protection
that are going to affect the system at all levels.
In 6.033, we use the work protection and security
essentially synonymous.
Often times we'll talk about a secure system or a system that
has security or certain security goals that we have,
so we're going to use those words interchangeably.
Security is one of these topicals
that you guys are familiar with to some extent already.
You've heard about various things
on the Internet going on where people's information has been
stolen on laptops or a website has been cracked into
or some worm or new virus, the new I
love you virus is spreading around
and confection people's computers.
So you guys are sort of familiar with it
on a collegial sort of way, I'm sure.
You also are familiar with many of the tools
that we're going to talk about, so
the applied versions of the many of the tools
that we're going to talk about.
You've all used a password to lock into a computer before
or you've used a website that using
SSL to encrypt the communication with some other website.
So you're going to be familiar with some
of many of the high letter instances of the tools
that we'll talk through in this session,
but what we're going to try to delve down into in 6.033
is how those systems are actually put together,
what the design principals are behind
building these secure systems.
As I said, you guys are presumably very familiar with,
you've heard about these various kinds
of attacks that are going on.
And one of the things that's happened in the last few years,
as the Internet has become more and more commercial and larger
and larger, is that it's meant that security of computers
has become much, much more of a problem.
So the growth of the Internet has spawned additional attacks.
If you go look at a website, for example,
there are several security websites
that track recent security breaches This is one example.
It's called Security Focus dot com.
I don't know if you can see these,
but this is just a list of things
that have happened in the last just few days on the Internet.
Somebody is reporting that web server hacks are up
by one-third, some IT conference was hacked,
Windows says "trusted Windows" is still coming.
[LAUGHTER] So it just goes on and on
with these are things that have happened in the last few days.
There is this huge number of things.
You may have heard recently about how
there have been several large companies recently that
have had big privacy problems where databases of customer
information have been stolen.
AmeriTrade just had this happen.
The University of California at Berkeley
had something like several hundred thousand applications
and graduate student records were
on a laptop that was stolen.
These are the kinds of things, the kinds of attacks that
happen in the world, and these are
the kinds of things that we're going
to talk about how you mitigate.
The objective, really, of security,
one simple way to look at an objective of security
is that we want to sort of protect
our computer from bad guys.
The definition of bad guy depends on what you mean.
It could be the 16 year old kid in his dorm room hacking
into people's computers.
It could be somebody out to sleep hundreds of thousands
of dollars from a corporation, but let's assume
that there are some bad people out there who
want to sort of take over your computer.
But, at the same time, the objective of security
is also to allow access to the good guys.
So one way to make sure that the bad guys don't get at your data
is simply to turn your computer off, right?
But that's not really a good option.
We want the data to be available to the people who need the data
and have the rights to access the data.
Often times we can sort of frame our discussion,
we can say that we're trying to protect
we have some set of information that we want to keep private.
So sort of a goal of a secure system, in some sense,
is providing privacy.
So we have some set of data that's on our computer system
or that's being transmitted over the network
that we want to keep private, we want
to keep other people from being able to have access
to or tamper with.
And throughout the sort of notion
of what it means for a computer system to be secure
is sort of application dependent.
It depends very much on what the computer
system we're talking about is.
It may be the case that in your file system,
you have a set of files that you want the entire world
to have access to, stuff that's on your webpage they're
willing to make public.
You don't have any real security concerns about who can read it.
But, at the same time, you might have banking data
that you really don't want people in the outside world
to be able to access.
So you have a set of policies that define, in your head,
some sort of set of policies or rules
about what it is that you would like
users to be able to access.
So almost any system has some policies
associated with data should be accessed by other people.
Some notion of what data they want
to keep private that can be sort of translated
into this set of policies.
So in 6.033 it's sort of hard to study in a systematic way
different types of policy.
Policy is something that we're not going to have,
we could sit around and have an informal discussion
about different possible policies that you might want.
But instead, in 6.033, what we're going to do,
as we've done in much of the rest of the class
is talk about mechanisms that we can
use to enforce these different security policies that someone
might have.
So we're going to talk about the tools
that we use to protect data.
In thinking about security and in thinking
about these mechanisms, it's useful to start off maybe
by thinking about what we mean by security and protection
in the real world and sort of compare the mechanisms that we
have in the real world for protecting data from, say,
mechanisms that we have on the computer.
From the point of view of what we
might want to accomplish with a secure computer system,
some of the goals and objectives are
similar to what we have in the real world.
Clearly, we have this same objective
which is to protect data.
We can say, just like in the real world,
we have a lock on a door that protects somebody
from getting access to something we
don't want them to have access to.
In the world of computers, we can encrypt data
in order to make so somebody who we don't
want to have access to our data doesn't have access
to that data.
Similarly, there are also, say, for example, in the real world
a set of laws that regulate who can access what data and what's
legal and what's not legal.
It's not legal for me to break into your house
and take something from it.
Similarly, it's not legal for somebody
to hack into a computer and steel a bunch of files.
There are also some differences.
The obvious one is one that has been true of almost all
of our comparisons between the real world
and, say, normal engineering disciplines that
involve building bridges and buildings and computer systems.
And that's this issue that computer systems
have a very high dtech over dt.
So the computer systems change quickly.
And that means there is always both new ways in which
computers systems are connected to the world,
there are new and faster computers
that are capable of breaking encryption algorithms
that maybe we didn't think could be broken before,
there are new algorithms being developed both for protecting
data, and there are new strategies
that people are adopting to sort of attack computers.
In the recent years we've seen this thing where people are
doing what they call phishing, P-H-I-S-H-I-N-G.
Where people are putting up fake websites that look like real
websites.
So all these emails that you get from Bank One
or whoever it is saying come to our website, click on it
and give us your social security number and your credit card
number, I hope you guys aren't responding to those.
Those are fake websites and people are trying
to steal your information.
We see new attacks emerging over time.
The other kinds of things that we see that are different,
clearly computer systems are, a tax in computer systems
can be both very fast and they can be cheap.
So, unlike in the real world, in a computer system
you don't have to physically break into something.
You can do this very quickly over a computer system.
So you see, for example, with some
of these warms and viruses, these things spread literally
across tens of thousands of computers
in a matter of seconds.
So these are very efficient and effective attacks
that can take over a huge number of computers
in a very short period of time.
And that leads to us wanting to have a different set of sort
of mechanisms for dealing with these kinds of problems.
And then, finally, it is also the case
there are some differences in between laws and computer
systems and in the real world.
In particular, because the computer systems
change so fast because new technologies develop so fast,
the legal system tends to lag significantly
behind the state of the art and technology.
So the legal system often doesn't
have regulations or rules that specifically
govern whether or not something is OK or is not OK.
And that means sometimes it's unclear
whether it's legal to do something.
So, for example, right now it's not clear
whether it's legal for you to take your laptop out
in the City of Cambridge, open it up and try and connect
to somebody's open wireless network.
Certainly, you can do that, it's very easy to do,
probably many of us have done this,
but from a legal standpoint there
is still some debate as to whether this is OK or not.
What this suggests, the fact that laws
are often unclear, ambiguous or simply unspecified
about a particular thing is that we're
going to need additional sort of sets
of, if you really want to make sure your data is secure,
if you want to enforce a particular security
policy you're going to need to rely more on sort
of real mechanisms in the computer software to do this
rather than on the legal system to say, for example, protect
you from something that might be happening in the outside world.
Designing computer systems is hard.
A secure computer system is hard, in particular.
And the reason for that is that security, often
times the things we want to do in secure systems,
the things we want to enforce are so-called negative goals.
So what do I mean by that?
An example of a positive goal is,
for example, I might say Sam can access pile F.
That, presumably, is something that is relatively easy
to verify that that's true.
I can log onto my computer system.
And if I can access this file F then,
well, great, I can access the file F.
We know that's true.
And that was easy to check.
Furthermore, if I cannot access the file and I think that I
should have the rights to access it,
I'm going to email my system administrator and say, hey,
I think I should be able to access this file, why can't I,
will you please give me access to it?
An example of a negative goal is that Sam
shouldn't be able to access F.
At first it may seem that this is just the same problem
as saying, it's just the inverse of saying Sam cannot access F,
but it seems like it should be just as easy or hard to verify.
But it turns out that when you're thinking about computer
systems, this sort of a problem is very hard
to verify because, while it may be true that when
I try and open the file and I log into my machine
and I connect to some remote machine
and try and access that file, it may be the case
that the file system denies me access to that file.
But I may have many other avenues for obtaining access
to that file.
For example, suppose I have a key
to the room in which the server that hosts that file is stored.
I can walk into that room and may
be able to sit down in front of the consol on this machine
and obtain super user route access to that machine.
Or, I may be able to pull the hard drive off the machine
and put it into my computer and read files off of it.
Or, I may be able to bribe my system administrator
and give him a hundred dollars in exchange
for him letting me have access to this file.
So there are lots and lots of ways
in which users can get unauthorized or unintended
access to files or other information
in computer systems.
And verifying that none of those avenues
are available to a particular user is very hard.
Worse, or similarly, this is hard
because it's very unlikely that a user is
going to complain about having access to some file
that they shouldn't have access to.
I'm not going to call up my system administrator and say,
hey, I have access to this file, I don't think
I should have access to it.
Nobody is going to do that.
So, even though I'm not a malicious user,
I don't really have any incentive
to go to my system administrator and tell them
that there's this problem with the way
that things are configured on the computer.
And that extends also to people who,
in fact, are malicious users.
When somebody breaks into a computer system,
they don't typically, usually, send out
an advertisement to everybody in the world saying, hey,
by the way, I got access to this file
that I should have access to.
It's possible for them to log in, read the file, log out,
and nobody would be any of the wiser.
Many of our security goals are negative,
and that means building secure computer systems is hard.
What we're going to do in 6.033, in order to get at this,
get at sort of building secure systems
in the face of these negative goals,
is look at a set of different security functions
that we can use to protect information
and access to computers in different sorts of ways.
And we're typically going to talk about,
throughout this, a client server sort of a system
where you have some client and some server that are separated,
typically over the Internet, that are sort of trying
to exchange information or obtain information
from each other in a way such that that information
exchange is protected and secure and so on.
Suppose we have a client sending some information out
over the Internet to some server.
What are the kinds of things that we want to make sure,
what are the sorts of security goals
that we might want to enforce in this environment?
One thing we might want to do is authenticate the client.
The server might like to know for sure
that the person who issued this request
is, in fact, the client.
They'd like to have some way of knowing that the client issued
this request and that the request that was sent
is, in fact, what the client intended to be sent.
For example, that somebody didn't intercept this message
as it was being transmitted over the network,
change it a little bit and then send it
on making it look as though it came from the client.
There might be different kinds of attackers that
are sitting in this Internet.
For example, there might be say an intermediate router
along the path between the client and the server
where the system administrator of the router is malicious.
Oftentimes, in the security literature,
there are these funny names that are
attached to the different people in different places.
Oftentimes the client is called Alice and the server
is called Bob, the person receiving the request.
And we talk about two different attackers.
We talk about Eve who is an eaves dropper who
listens to what's going on and tries to acquire information
that she's not authorized to have
and we talk about Lucifer who is the bad guy who
not only is trying to overhear information
but may do arbitrarily bad things.
He's trying to take over the data
and corrupt it in any way he possibly can.
One goal is that we want to prevent, say,
for example, Lucifer from being able to interfere with packets
coming from Alice to Bob.
We want to make sure that packets the server
receives actually originated from Alice
and were the original request that Alice sent,
so that's authentication.
We also might want to authorize, at the server, that Alice is,
in fact, allowed to access the things that she's
trying to access.
If Alice tries to read a file, we
need some way of understanding whether Alice is allowed
to access this file or not.
We also need to keep some information confidential.
We may want it to be the case that Eve,
who overhears a packet, cannot tell what the contents of that
packet are.
We might want to be able to protect the contents of that
thing so that Eve cannot even see what's going over
the network.
So notice that this is a little bit
different than authenticating.
Authenticating says we just want to make
sure the packet, in fact, came from the client.
But we're not saying anything about
whether or not somebody else can see
the contents of that packet.
Keeping confidential says we want to make sure
that nobody, except for the intended recipients
can, in fact, see the contents of this.
There are a couple other properties
that we want as well.
One thing we might want is accountability.
We're going to talk about this a little bit more.
This says we need to assume that it's always possible
that something could go wrong.
It's always possible that I might
have bribed my assistant administrator
and he might have given me access to the computer.
And, in the end, there is not much you're going
to be able to do about that.
What you want to do is make sure that when situations
like that occur that there's some log of what happened,
you have some way of understanding
what it was that happened, why it happened
and how it happened so you can try and prevent it later.
You want to make sure you do a counting,
you keep track of what's been going on.
And, finally, you might want availability.
This is you might want to make sure that Lucifer,
who is sitting here between the client and the server cannot,
for example, send a huge number of packets at the server
and make it unavailable, just swamp it with a denial
of service attack.
Availability means that this system, in fact,
functions and provides the functionality
that it was intended to provide to the client.
We are going to spend a while in 6.033 especially focusing
on these first three techniques.
Essentially, the next three lectures
are going to be talking about how we guaranty,
how we authenticate and authorize users
and how we keep information confidential and private.
But all of these goals together there
is a set of technical techniques that we
can talk about for trying to provide
each one of these things.
But when you think about building a secure system,
it's not enough to simply say we're
going to employ, you know, I employ authentication to make
sure that Alice is, in fact, Alice when she talks to Bob.
What you want to do, when you build a secure system,
is think about sort of how to, you
want to get your mindset around building
sort of the general ideas behind a secure system.
And so, in 6.033, we have this set of principles
that we advocate called the safety net approach.
And the idea is the safety net approach is a way
to help you sort of in general think about building
a secure system as opposed to these specific techniques
that we're going to see how to apply later on.
The safety net approach advocates
sort of a set of ways of thinking about your system.
The first one is be paranoid.
This is sort of the Murphy's Law of security.
It says assume that anything that can go wrong
will go wrong.
Don't just assume that because you're authenticating
the communication between Alice and Bob
that there is no way that somebody else will pretend
to be Alice.
You should always have something, a safety net,
some backup to make sure that your system is really secure.
A good example of being paranoid and applying
the safety net approach are things
like suppose your router has a firewall on it,
suppose your home router has a firewall that's
supposed to prevent unauthorized users from being able to access
your computer, does that mean that you should then turn off
all password protection on your computer
so that anybody can log in?
No, you're not going to do that.
You're going to continue to protect
the information on your computer with the password
because you may have a laptop and may not
be using it from home.
Or, you may be worried about somebody
breaking into your computer from inside of your house,
say, perhaps.
That's an example of sort of thinking about the safety net
approach.
You have multiple layers of protection
for your information.
There are some sort of sub-approaches,
there are some sort of sub-techniques
that we can talk about in the context of being prepared.
One of them is accept feedback from users.
If you were designing a big computer system
and somebody tells you that something is secure
or that there is a problem, be prepared
to accept that feedback, have a way to accept that feedback
and respond to that feedback.
Don't simply say oh, that's not a real security problem, that's
not a concern or don't, for example,
make it so the users don't have a way to give you information.
Defend in depth.
This is have multiple security interfaces
like passwords plus a firewall.
And, finally, minimize what is trusted.
You want to make sure that the, and this
is sort of a good example, we've talked
about this as an example of system design before.
We want to try and keep things as simple as possible,
but this was really important in the context of security
because you want to make sure, for example, that you try
and keep the protocols that you use
to interact with people from the outside world as
simple as possible.
The more interfaces that you have
with the outside world that users can connect
to your computer over, the more places you have
where your computer system is vulnerable.
So you want to try and minimize, make it
so that your computer system has as few sort of openings
it can that you have to verify our securer as possible.
Other examples of the safety net approach,
you need to consider the environment.
This just means it's not enough, you know,
suppose that I have this connection
here, this connection over the Internet between Alice and Bob,
I may assume that I'm only worried about attackers
who are coming in, say, for example, over the Internet.
But if you're a server, the server
may have other connections available to it.
So it may be the case that this is a server
inside of some corporate environment
and this server has a dialup modem connected to it.
Especially, nowadays, this is less common,
but it used to be the case that almost all companies had
a way that you could dial in and get access to a computer
when you didn't have a wired Internet
connection available to you.
And often times this dial-in access was a separate place
where people could connect.
So, for example, it didn't have the same interface
as the sort of main connection to the Internet.
And that meant that there was sort of side channel,
in the environment, through which people could use
to get access to the computer.
Similarly, this means you should think about all the people who
have access to the computer.
Is it the case maybe that this is a computer in your office
and the janitor who works in your office comes
into the office every night, would he or she
be able to sit down in front of your computer
and get access to the system when they shouldn't be able to?
And this may sound paranoid.
It is being paranoid, but if you really
want to build a secure computer system
you need to sort of keep all these things in mind.
Need to plan for iteration.
This is, again, just a good system design principle,
but it's especially true here.
Assume that there will be security violations
in your computer system, assume there
will be security problems, and plan
to be able to address those problems
and also have a way to verify that once you've addressed
those problems the other parts of your system
that are supposed to be secure continue to be secure.
And, finally, keep audit trails.
This gets at our goal of accountability.
This just means keep track of everything.
All of the authentication and authorization requests
that you made in your system, when a user logs in,
keep track of where they logged into, maybe
even keep track of what they did so that you can come back,
if it turns out that this person was unauthorized,
you later discovered that they were up to no good,
you can come back and understand what it is that they did.
What all this sort of discussion,
especially this discussion about the safety net approach
illustrates or gets at is that there are lots of these issues
that we're talking about.
So, for example, the janitor breaking into our computer
or me bribing my system administrator.
There aren't really computer system issues, right?
These are human issues.
These are things that I'm bypassing
any sort of authentication I might
have in the computer or any kind of security
that I might have built into the computer
because, for example, my system administrator is authorized
to access anything on the computer he wants to.
And so I have, essentially from the computer systems
point of view, made it look like I have rights
to get at anything I want to if I can
bribe the system administrator.
So this suggests that sort of in many computer systems humans
are the weak link.
Not only are people bribable but people make mistakes.
People don't read dialog boxes.
People do things hastily.
People don't pay attention.
The reason that these phishing attacks work where somebody
pretends to be Washington Mutual or eBay
and sends you an account that asks you to log in
and type in your social security number
is that people don't think.
They just see this email and say oh, I
guess eBay wants me to give them my social security number.
OK.
People make mistakes.
And this is the way that many, many security vulnerabilities
or security problems happen is through people mistakes.
So we're going to talk in most of 6.033
about technical solutions to security problems.
But, when you're actually out in the world building a system,
you need to be thinking about the people who
are going to be using this system
almost as much as you're thinking
about the sort of security cryptographic protocols
that you design.
That means, for example, you should
think about the user interface in your system.
It does the user interface to promote sort
of users thinking securely.
The classic example of sort of a bad user interface
is your web-browser popping up this dialogue
box every time you access a site that isn't SSL encrypted saying
this website is not SSL encrypted, are you sure
you wish to continue?
And, after it has done this about ten times
and these are sites that you know and believe
are safe like almost any site on the Internet,
you just click the dialogue box that says never
show me this alert again.
There is almost no useful information
that the system is giving you by complaining in that way.
Other examples of things you want to make sure you do
is have good defaults.
In particular, don't default to a state
where the system is open.
When an error occurs, don't leave the system in some state
where anybody can have access to anything that they want to.
Instead, default to a state where people don't have access
to things so that you're not exposing
the system to failures.
Don't default to a password that anybody can guess.
When you create a new user for your system
don't make the default password PASSWORD, that's a bad idea.
Make it some random string that you email to the user
so that they have to come back and type it in.
Finally, give users least privilege
needed to do whatever it is they need to do.
This means don't, by default, make users
administrators of the system.
If the user doesn't need to be an administrator of the system,
they shouldn't have administrative access,
they shouldn't be able to change anything that they want.
A good example of least privilege being violated
is many versions of Microsoft Windows, by default,
make the first user who is created an administrator user
who has access to everything.
And this is a problem because now
when somebody breaks into that users
account they now have access to everything on the machine,
as opposed to simply having access
to just that user's files.
In general, what this just means is keep your systems simple,
keep them understandable, keep the complexity down.
And that's sort of the safety net.
There are these two principles that you want to think about.
One, sort of be paranoid.
Apply this notion of having a safety net in a computer
system.
And, two, don't just think about the technical protocols
that you're going to use to enforce access to the computer
but think about sort of who is using this system,
think about humans who have access to it,
and think about how to prevent those humans from being
able to do stupid things that break your security
goals for your system.
This was a very sort of high-level fuzzy discussion
about security.
Now what we're going to do is we're
going to drill in on some of these more
specific technical protocols.
And today we're going to look at a way in which you can think
of most secure systems as consisting of a set of layers,
and those layers are basically as follows.
We have, at the top, some application
which we want to secure.
And then underneath this application
we can talk about three layers.
So we have some kind of functionality
that we want to provide, we have some set of primitives
that we're going to use to provide that,
and then, at the very bottom, we have cryptography which
is the set of mathematics and algorithms
that we're going to use that we generally, in modern computer
systems, use to make sure that the computer system is secure.
The application may have its high-level functions that
correspond to these things over here,
so we may want to be able to authenticate users
or we may want to be able to authorize
that users have access to something
or we may want to provide confidentiality.
So we may want to be able to make sure
that nobody can read information they don't have access to.
So you're going to have a set of primitives for doing
these different things.
For authentication, we're going to need to talk about something
called an access control list.
For authorization, we're going to talk about primitives
called sign and verify.
And for confidentiality we will talk about these primitives
called encrypt and decrypt.
And these topics, this stuff that's
in this middle set of primitives,
we're going to describe these in more detail in later lectures.
What I want to do with the rest of the lecture today
is to talk about this bottom layer, this cryptography layer.
We have some set of cryptographic ciphers
and hashes.
And so a cipher is just something
that takes in, say, a message that the user
wants to send that is not protected at all.
And it flips the bytes in that message around
in order to create something that is not understandable
unless you have some piece of information that allows
you to decipher that message.
You can say ciphering and deciphering
is sort of like encrypting and decrypting,
words you may be familiar with.
We also talk about hashes.
Hashes we're going to use to authenticate or to authorize
a particular message to make sure that a message is --
I'm sorry.
Just for your notes, I got this backwards.
This should be authenticate with sign and verify
and we authorize with ACL.
We'll talk about these things more in a minute,
but it was just confusion over two words that start with auth.
So we're going to use hashes to basically authenticate
that a user is, in fact, who they claimed that they were.
And, again, we'll see in more detail how this works
over the next couple days.
Early cryptographic systems relied on this idea, or early
cryptography relied on this idea that we're
going to try and keep the protocol that's
used for encoding the information secret.
A simple example of an early encryption method
might be something that many of you
played with when you were a kid where
you transpose all the letters.
You have some map where you A maps to C and B maps to F
and so on, some mapping like that,
and you use that to encrypt it.
And there are these puzzles where
you get told a few of the letters
and you try and guess what the other letters
and decode a message.
That's a simple example of a kind of encryption
that you might apply.
And that encryption relies on the fact
that this transform is essentially secret.
If you know the transform obviously
you can decrypt the message.
These schemes are often called closed design crypto schemes.
And the idea is that because the attacker doesn't
know what scheme was used to encode the information
it can be very, very hard for them to go about decoding it.
For example, the architecture for this
might look like message goes into some encryption box which
is secured from the outside world.
It was just hidden from the outside world.
Nobody else knows what that is.
And this goes over the Internet to some other decryption
box which then comes out on the other end as a message.
This is a closed design.
And these designs, in general, sort of
turn out not to be a very good idea because the problem is
if somebody does discover what this function is now
you're in trouble.
Now this whole system is no longer secure.
And, worse than that, when you make these things secure,
if you suppose now you're going to put this system out
in the world with a hidden protocol
that nobody knows in the world, now it's
sort of you against the whole world.
Whereas, if you had told everybody what the protocol was
to begin with and said this is the protocol
and there is this little bit of information
that we keep secret within the protocol,
the two parties in the protocol keep secret,
but here's the sort of algorithm that's in the protocol,
let's let the entire world verify
whether this protocol is, in fact, secure or not,
you'd have a much better chance of developing something
that was secure.
It is sort of accepted wisdom that these kinds
of closed design systems tend not to be widely used anymore.
The systems that we are going to talk about,
for the rest of this talk today, are
going to be so-called open design systems.
Of course, there are many, many systems
that were designed with this and there are many, many closed
cryptography systems.
And, in some ways, they're sort of the most natural ones
and the things you'd think of first.
And they've been very effective throughout history.
It's just the case that modern cryptography typically
doesn't rely on it.
Open design systems have an architecture that
typically looks as follows.
It is pretty similar to what we showed before.
We have m going into E.
But this time this protocol E, the world
knows what the algorithm E is and instead this E
has some piece of secret information coming into it,
a key, k.
And this key is usually not known to the world.
And now we go through the Internet, for example,
and we come out to a decryption box which
also has a key going into it.
And these keys may or may not be the same on the two boxes.
And we'll talk about the difference
between making them the same or not making them the same.
Now we have this message that comes out.
Message comes in, gets encrypted,
goes over the Internet, goes into the decryption box
and gets decrypted.
If k1 is equal to k2 we say this system
is a shared secret system.
And if k1 is not equal to k2 we say that this
is a public key system.
In k1 is equal to k2 these two keys are the same.
And, say, Alice and Bob on the two ends of this
have exchanged information about what this key is
before the protocol started.
Alice called up Bob on the phone or saw Bob in the hallway
and said hey, the key is X.
And they agreed on this beforehand.
And now that they've agreed on what this key is they
can exchange information.
In a public key system, we will see
the design of how one public key system works in a little bit
more detail, but typically it's the case
that, for example, the person who is sending the message
has a private key that nobody else knows, only they
know, and then there's a public key that everybody
else in the world knows and is sort of distributed publicly.
And these two keys are not equal but there
is some mathematical operation that you
can apply that, given something that's been encrypted with k1,
you can later decrypt it with k2.
And we will look at one example of one
of those mathematical functions.
The point here is closed design says the algorithm itself
is unknown to the world.
What shared secret simply says is
that there is some little bit of information, a little key,
like a number that we've exchanged,
but it's not the algorithm, it's not the protocol,
it's just this one little bit of, say,
several hundred bits of key information that we established
beforehand.
It still is the case that, for example,
this protocol in a shared secret system is published.
And so people can go and try and analyze
the security of this thing.
The community can look at what the math is that is going on.
Let's look at a simple example of a shared key system.
This is an approach called a one-time pad.
One-time pad is a very simple example
of an encryption protocol that is essentially
cryptographically unbreakable.
That is it may be possible to break it through other means
but it is sort of provably not possible to break this
through some sort of mathematical analysis attack.
One-time pad depends on the ability
of a source of truly random bits.
I need some way to generate a set of bits which
are sort of completely random.
And doing that is tricky, but let's suppose
that we can do it.
What one-time pad says, we're going
to call this sequence of bits k, that's going to be our key,
and this key and the one-time pad approach
is not going to be short.
This key is going to be very, very long.
It's going to be as long as all of the messages
that we possibly want to send over all of time.
Suppose that Alice and Bob, the way they generate
this is Alice writes a set of random bits onto a CD,
writes 650 megabytes of random bytes onto a CD
and gives that to Bob and they agree
that this is the key that they are going to use over time.
We have m and k coming in.
They are being combined together.
They are being transmitted over the Internet.
And then, on the other side, they
are being decoded also with k where
these two ks are equal in this case
and we've got m coming out.
This plus operation here is an XOR.
This plus with a circle is XOR.
If you were to remember what XOR does, the definition of XOR
is given two bytes, zero, one, two things that
were XORing together, two bytes that are either zero or one,
the XOR of two zeros is zero, the XOR of zero and one is one
and the XOR of two ones is zero.
XOR has this nice property.
This XOR is a byte-wise operation.
This says the first byte in k is XORed with the first bid in m
and the second byte in k is XORed with the second byte in m
and so on.
And the same thing happens over here.
XOR has the nice property that m XOR k XOR k is equal to m.
You can verify that that's true if you
look at a simple example.
What happens is when the stream m comes in and gets XORed
with k, the encrypted message that is traveling over here
essentially looks like a random byte string
because k is a random byte string.
And this m, no matter what m is, when
it is XORed with a random byte string
you're going to get something that looks like a random byte
string coming out.
And then on this other side, though,
we also have access to the same byte string that was used,
and now we can decrypt the message.
So only if somebody knows exactly what k is can they
decrypt the message.
This approach is hard to make work in practice
because it requires the availability of a large amount
of random data.
One thing that you can do is use a random number generator that
is seeded with some number and then
use that random number generator to begin to generate
the sequence of bytes.
Of course, that has the problem now
which is somebody can discover the seed or somebody can guess
which seed you used because the random number generator used
is not very good.
They may be able to break your protocol.
But on-time pad is a nice example of something
which is sort of a cryptographic protocol that
is known to work pretty well.
What I want to do, just with the last five minutes,
is talk about one specific cryptographic protocol which
is called the RSA protocol.
And we probably won't have time to go
through the details of how RSA actually works,
but RSA is a public key protocol.
And let me just quickly show you what RSA uses
and then we will skip over DES here.
What RSA does is says we are going to take
two numbers, p and q which are prime.
This protocol is in the book.
It is in appendix one of the chapter
so you don't need to copy it down word for word
if you don't want to.
If we have p and 1 are primes, we
pick two numbers p and q which are prime,
and then we generate some number n
which is equal to p times q and another number
z which is equal to p minus one times q minus one.
And then pick another number e which is relatively prime to z.
So that relatively prime just means
that e doesn't divide z evenly.
So z is not divisible by e.
And we pick a number d such that e times d is equal to one,
as long as the product [is modulo z?].
If you take e times d and you take the modulus with z
the value should be one.
If you pick a set of numbers that satisfy this property then
we can define the public key to be e,
n and the private key to be d, n.
And these numbers have this magic property.
And then we are going to be able to, with this,
encrypt any message that is up to n in length.
So, in general, we are going to want n and p
and q to be some set of very large numbers.
They are going to be hundreds of bytes long.
We are going to be able to encrypt
any message that is up to n bytes
long, it is up to size of n.
So we may have to break the messages up
into chunks that are size n or smaller.
This has this magic property now that if we encrypt the data
in the following way, to encrypt a message
we take m to the power of e and then take
the whole thing module n.
Now, transmit that message c across the network.
Now, to decrypt, we take that encrypted thing
and take it to the power d and then take the whole thing
modulo n, we get the original message out at the end.
The mathematics of understanding why this work turned out
to be fairly subtle and sophisticated.
There is a brief outline of it in the paper,
but if you really want to understand this
it's the kind of thing that requires an additional course
in cryptography.
We're not going to go into the details of the mathematics,
but the idea is suppose we pick p to be 47
and q to be 49, two prime numbers,
generate n to be 2773, just the product of those,
z then is 2668.
And now we pick two numbers e and d.
We pick these numbers just by using some searching
for these numbers somehow over the set of all possible numbers
we could have picked.
So we have these two numbers e and d
which satisfy this property.
That is 2668 is not divisible by 17, and 17 times 157 modulo
z, modulo 2668 is equal to one.
And you have to trust me that it true.
Now, suppose we have our message is equal to 31.
If we compute now C is equal to this thing, 31
to the 17th modulo 2773, we get 587.
And then, sort of magically at the end, we reverse this thing
and out pops our message.
What we see here is a public key protocol.
What we say here is the public key
is equal to this combination of e and n and the private key
is equal to this combination of d and n.
Suppose that only Alice knows the private key
and that Bob knows the public key and everybody
else in the world, for example, knows what the public key is.
Now, what we can do is Alice can encrypt
the message with her private key which nobody else knows.
And then using the public key everybody else
can go ahead and decrypt that message.
And by decrypting that message they
can be assured that the only person that could have actually
created this message to begin with
is somebody who had access to Alice's private key.
So they can authenticate that this message came from Alice.
This protocol also has a nice side effect
which is that it is reversible.
If Bob encrypts a message using Alice's public key,
Alice can decrypt that message, and only Alice
can decrypt that message using her private key.
We will talk more about these properties next time.
And take care.