Hello and welcome to this fundamentals of cryptography course.
So far in this sequence of videos about asymmetric cryptography, we've been talking mostly about theory
and algorithms, talked about the fundamentals of asymmetric cryptography, these hard problems that
make asymmetric cryptography possible.
And a few of them are commonly used asymmetric encryption algorithms.
In this video, we're going to start with the first of two videos about applications of public key cryptography.
Beyond the obvious application of encrypting data in this one, we'll talk about public key infrastructure,
also known as Piqué I.
We have four main topics in this video.
We're going to start out with an introduction to public key infrastructure.
Then move on to a discussion of certificate chains and asymmetric cryptography.
Next, we'll talk about the applications of public key infrastructure, what it's good for, and then
close out by discussing some of these security assumptions that Piqué II makes and why these might not
always be valid.
So let's get started by introducing public key infrastructure.
So Piqué AI is designed to create a chain of trust.
You have a theoretically trusted entity at the top of the chain and that entity belches for the validity
of the next link in the chain and so on and so forth until you reach the bottom of the chain.
And so if you trust the top of the chain, you trust the bottom of the chain and you trust the vouching
process.
You can trust the person at the bottom of the chain.
And so this vouching process is performed by digitally signing a certificate, the certificate has data
in it about a particular entity and the certificate above it signs a certificate saying, I vouch for
the validity of this data.
And this process of vouching and enables a certificate authority to delegates certain powers to its
subordinates.
For example, there's this certificate authorities here that are responsible for the dot com top level
domain on the Internet.
Those dot com domains have the ability to delegate powers to say Google dot com.
And so the top level domain.
Com says Google dot com is a valid domain.
This is the information about the organization that owns it.
And they have full control over Google dot com.
And then these subordinates can perform additional delegation isn't necessary.
So Google dot com has domains like mailed out Google dot com, which can have their own digital certificates
and they could govern themselves, but they're vouched for by Google dot com.
And further up the chain, dot com itself.
And how this works is through certificate chains and asymmetric cryptography.
So trust in PCI is implemented as a chain of digitally signed certificates at the very top of the chain.
You have a root certificate.
So this certificate is self signed, meaning it's signed with its own private key and which is a signature
that can be verified with the public key included in the certificate.
And this route, CIA is trusted by default.
Your computer has a list of Route CEAS that it trusts.
And so any cert chain that is routed with that route seeI is trusted by your computer.
And so after the route, CIA, every other certificate in the chain is signed by the next highest certificate
in the chain.
So the route seei sign sister certificate, which could sign another certificate, etc. until you reach
an end user certificate.
That end user certificate could can have its chain of trust traced back to a trusted route c.a.
You go and verify the digital signature on that end user certificate if it's valid.
You go look at the next certificate up the chain, check its digital signature and so on and so forth.
You reach a route s.a.
If you trust that route seei then you can trust the end user certificate as well.
And so this chain of trust enables delegation of trust down the chain.
And so why do we care about public key infrastructure?
It's actually used for a variety of different purposes, many of which we see in the real world.
One example is a P.S. enabled Web sites.
When you're using a Web browser, you're on a Web site and you see that green lock icon.
What that means is that somebody has a digital certificate for that Web site and it's sent along with
the site and everything checks out.
Well, if you've ever open that certificate and looked at it, you're probably going to see a certificate
chain.
What you'll see is that that site will have been signed by one or more certificate authorities in a
chain up to a root certificate authority.
And if that Route SCA is trusted by your computer, then you can trust the Web site as well.
Another application is code signing.
So, for example, on mobile phones like iPhones, it's not possible for an application to run on a
non jail broken phone unless it's digitally signed by a certificate that has been issued by Apple.
So Apple signed certificates which are used to sign the code, and that allows it to run on your phone
because it means that Apple said this application has our blessing and consent to run on our phones.
You can bypass this through jailbreaking, but by default, the secure option is to leave it on jail,
broken and take advantage of the trust associated with those digital certificates.
Another application is SSA Keys.
You can have LSH or Piqué I implemented within organization and use SSA keys to authenticate to computers.
You can also use it for email signatures where the sender of an email is verified using Piqué ie to
ensure that that hasn't been spoofed or been used as part of a phishing attack.
And so all of these applications are all well and good for Piqué.
But they're only useful if you can actually trust the Piqué I.
And so, Piqué, I makes a few security assumptions.
The first of these is that the root of trust is trustworthy.
Your computer has a hard coded list of CERT authorities that it trusts Bayt that are selected by the
manufacturer.
And so depending on your personal threat model, level of trust, et cetera, you may not trust some
of the CIA that they've included because you may feel that, oh, they might be too closely associated
with a government that could exert pressure on them to create invalid certificates.
Or the organization has been known to create fraudulent certificates.
You don't want to trust it, et cetera.
There might also be C.
A's that you trust that aren't included, that you can add after the fact.
But it all boils down to whatever list that you have on your computer of Root CEAS that are trusted.
If any of them can create a certificate chain that your computer will trust.
Second assumption is that private keys are appropriately protected if someone steals the private key
of a root certificate authority or any certificate authority, they can generate valid certificates
for anything under their domain of influence.
If you steal Google scums private key, you can generate your own certificates for mail, dot, Google,
dot com or whatever you want.
And they'll be verifiable because the digital signatures are valid and it traces back eventually to
a trusted, rootsier.
And thirdly, we have the assumption that the asymmetric cryptography algorithms are secure.
And this is probably the strongest of our assumptions here for the time being, the long term with quantum
computing, some algorithms that we use will no longer be trusted and we'll have to transition to something
else.
And so these three assumptions are important to the security of PCI, if they are violated, the entire
system falls apart.
If cryptographic algorithm is insecure or someone breaks it, then you can't trust chains of trust.
If private keys have been stolen from a CIA, you can't trust it.
And that CIA is probably going to have to start from scratch, generate a new private key, regenerate
every valid certificate it's created, and invalidate or revoke every one that was previously created
and potentially fraudulently created.
And thirdly, you have to assume that the route of trust is trustworthy.
If someone hacks a route seei or the route seei is coerced into taking illegal actions and generating
fake certificates, then any digital certificate rooted with that seei can't really be trusted anymore.
And so piqué AI is useful but it's fragile.
Every link in the chain has to be secure and you have to have a secure route seei in order for it to
be trustworthy.
So just as a recap, this video designed to provide an introduction to an application of public key
cryptography, namely Piqué, I start out with an introduction to Piqué.
I talked about how it works with cert chains and asymmetric cryptography, discussed a few applications
of PCI and then talked about these security assumptions that have to be true for PCI to be secure.
Thank you.