One of the big challenges to using asymmetric encryption is the fact that well if you're going to do
asymmetric encryption you're going to generate a public, public keys will be red this time, and a private
key so you're going to generate this key pair.
Now in this particular example let's say that I'm a web server and I own a company called Total seminars
and the Web site is www.totalsem.com and I want people to be able to buy stuff on my web site.
So I want to set up a secure web server so in the most simple world what I would do is I would generate
a public and private key pair and anytime anybody logged into my website I would automatically just
send them this public key and then that way we could start asymmetric encryption. Well that's a problem.
That's a big problem.
The problem with asymmetric encryption is the public key. If you get a public key from somebody and by
the way when you log into a secure Web site when you type in HTTPS colon backslash www.ebay.com
you automatically get the public key sent from that web site straight to your system.
OK.
So it's not like e-mail where we have to send it via e-mail or anything like that.
But the problem is is do you as a person who is running a little web client do you know what this public
key is for www.ebay.com?
Yeah it may say it up on the screen but there's ways to get around that.
So the problem with asymmetric encryption is not the public private key.
That works pretty much perfectly.
The problem is in the key exchange How do you know A where did this public key come from?
And B is it the person that you think it is?
So there's two problems here.
So in order to get around this there's actually something really cool I want to tell you about.
Now remember we've said in previous episodes that you always encrypt with the public key and you decrypt
with the private key.
And that's true.
But I will let you in on a little secret.
There is no difference between a public and a private key.
I mean they're different numbers.
They're just binary strings and they're different binary strings.
But there's nothing special about the public key that it can only encrypt.
There's nothing special about the private key that it could only decrypt. When you generate a public
private key pair either one of these could be the public key just by convention we pick a particular
one.
So again the public and private key are just a string of ones and zeros they're different strings but
they're just strings of ones and zeros.
Anything you encrypt with this can be decrypted with this anything you encrypted with this can be decrypted
with this.
Now we never do that.
We never never ever do that.
The reason we don't do it is because if we started to encrypt with both sides of this there are ways
that it can be hacked and naughty things happen. We don't want to ever do that.
However there are some cool things we can do.
Let me give you one example.
So again I'm going to go back to www.totalsem.com, I generate a public and private key you log into
my website.
Got it.
Now what I'm going to do is I'm going to send you the public key but I'm not going to send you the public
key by itself what I'm going to do is I'm going to take the web page that you're on right now whatever
that web pages and I'm going to encrypt it and encrypt it with my private key and then I'm going to send
you a hash of that web page.
Got the idea.
So when I send you my public key I'm not just sending you the public key.
I'm going to literally take the entire web page encrypt it with my private key and then I'm going to
make a hash out of it and I'm going to send you not only my public key but a hash of the page that you're
on right now what you can do is because you're getting that web page to is with your public key
you can encrypt that entire web page it's the exact same page hash it and compare the hash that I sent
you with the hash that you've generated and you now know without any question whatsoever that whoever
is associated with this private key has sent you the public key.
Do you understand the power of that?
It gives us a little bit of a tool that says: Yep,
whoever has this private key has sent me this public key and we call that a digital signature. A digital
signature is just a hash.
That's all it is.
So if it's a web page we hash we encrypt and hash the web page.
If I'm sending you a public key for email encryption whatever e-mail that I'm sending you at that moment
I'm going to go ahead and encrypt it and hash it and whatever it is we have now generated a digital
signature and a digital signature is nothing more than a hash of whatever chunk of data that you happen
to be looking at encrypted chunk of data that says this had to have come from this private key.
Well that's great but it's not complete.
See the problem what we run into now is that now
again let's go back to my www.totalsem.com.
And so you go on www.totalsem.com and you go and you want to start buying stuff and it kicks over into
a secure web page.
So boom comes down the public key boom comes down my digital signature.
Did it really come from www.totalsem.com?
.
I mean sure.
It says www.totalsem.com but I can beat that.
There are ways that I can spoof those addresses and fool you.
Or what if I stole somebody else's certificate.
What if I stole a certificate from www.intel.com and pass that down.
The problem you have now is that you can't say for sure that I Mike Meyers am the person. Or I
totalsem.com am the person from which this public private key pair was generated.
So to get around that what we're going to do is you and I are going to shake hands and before we start
doing any business we're going to agree on a third party.
Let's say you and I both know my buddy Ginnell.
All right.
So what I'm going to do is I'm going to go to Ginnell and I'm going to say hey Ginnell I would like you
because you and I know each other we've been friends for 30 years.
I want you.
And by the way you have one of my public keys I have your public key whatever what I need you to do
is generate your own digital signature not based on this relationship here,
but based on your and my relationship and what I'd like to do is attach that digital signature to my
public key along with my digital signature.
So what we've done now is we have a public key and this public key says well this is my public key then
we have a digital signature which guarantees that whoever actually owns that private key is associated with
that public key and then we have a third party that says yep I guarantee as much as money and law will
allow. That
this is Mike Myers and that's www.totalsem.com website and it is OK.
So this all sounds pretty good but we don't ever send public keys by themselves.
We don't send piles of keys with all these digital signatures I guess with e-mail we could make three
attachments or something.
What we do instead is we generate something called a digital certificate. A digital certificate is a
document it's like a word document.
It's like a halfway filled in Word document and you'll see you fill in the blank spots.
And if you send anybody a public key you don't send a public key by itself.
It's never done.
You send a certificate and inside that certificate is going to be my public key.
It's going to have to make sure you get the right one is going to have my digital signature.
Knowing that it came from my key pair.
And it's going to have the third party that you and I trust that says yep this is really Mike Meyers
what we'd normally do is we go to a third party and we go: would you create me a certificate? And that
person knows us in some fashion.
We have met with them.
They know my company whatever it is and they will and they already have my public key.
So if they don't I can hand it to him.
Give him a public key give him my digital signature and then they will generate a certificate.
It's the actual process of generating certificate is trivially easy.
You can do it any copy of Linux any copy of Microsoft Windows and you can generate the certificate.
They'll generate the certificate.
But what they do that makes it important and good and amazing is that they add their third party digital
signature that says: I'm good.
And that's where the challenge comes in.
Oh and by the way once I have the certificate I can pass it out to anybody.
I take the certificate put it into my web server and any anytime anybody logs into my web server and
wants to go secure and then boom they automatically get a copy.
I can if I want to do this for e-mail I can take the certificate embed into any email not an encrypted
email just a regular email go hey here's my certificate.
We pass out certificates like crazy because this is how we move public keys.
OK.
The trick here is who do you trust.
Because the whole power of a certificate is that we have people that we trust well that the two sides
of this equation trust and say yep this is somebody I'm going to trust and do business with.
So there's really three ways to do trust.
The first way to do trust is to generate a certificate on your own.
Forget the third party just make your own certificate.
It's easy enough to do.
And that's called an unsigned certificate. Unsigned certificates are fantastic as long as both people
understand that there is no third party vouching for you.
We use unsigned certificates here at total seminars.
I have some in-house web servers and people want to access them.
We all know each other I mean you can't even get to this web server unless you're an employee of mine.
So unsigned web servers are very common and they work fine but only if you have some other form of trust
like you work for me.
Other than that you've got two other choices.
Web of trust and PKI.
So let's start with web of trust.
I got a little graphic for you to show you how that works.
So here's me and I want to get a certificate. Now in order for me to get a certificate
in this particular situation this web of trust we don't have a particular authorities so what I have to do is
find other people who are using this type of certificate.
So here's a couple of people I know and I can get them to sign my certificate.
Now depending on how this is done and you see this with e-mail a lot of times you almost never see this
on web browsers.
What will happen is that I will have to probably call this person on the phone.
I might have to send him a photocopy of my driver's license it really just depends on how rigorous a
particular web of trust is.
And now these web of trust can grow so let's make this a little bit bigger.
And over time with a web of trust you end up having a fairly complicated setup where you have a lot
of people who trust each other.
Web of trust works beautifully as a trust model for certificates but it has some problems.
The big problem of the web of trust is that it requires a lot of people doing a lot of work to administer
and make this happen.
There's very little to web of trust that's in essence automated.
You've got to work hard to keep it up and going.
That's why web of trust has never really taken off it's had its moments for e-mail certificates.
It's had its moments for, believe it or not,
even hard drive encryption and stuff like that.
But if you really want to do trust with certificates the right way you do something called public key
infrastructure. Public Key Infrastructure is a hierarchical method that starts off with root servers up
at the top intermediate servers and goes down to users so there's always a boss at the top.
Let me show you how this works. Public Key Infrastructure is based on the idea of a hierarchy. At the
top of this hierarchy are what we call the certificate authorities. A certificate authority is an organization
that pretty much just issues certificates.
These are usually big companies.
Probably the most famous is Verisign but Thawte would be another name that comes to mind.
There's just a few hundred of these and these organizations simply based on the full faith and credit
of your and my trust in them generate certificates that everybody knows and recognizes. Now if we have
a lot of people who are going to these certificate authorities the challenge we run into is that they
can be kind of busy.
So normally what we'll do is between us the users of those certificates and the certificate authorities
are intermediate certificate authorities who are only there to take the load off of the certificate
authority themselves.
So basically we have a nice little hierarchy like this. PKI is the way we do the Internet.
If you're going to be dealing with certificates on the Internet particularly in an e-commerce way you're
going to be dealing with PKI and anybody who's ever set up a website that actually uses HTTPS realizes
that you've got to go to people like Verisign and Thawte and folks like that.