Instructor: So first, an overview of
encryption mechanism.
And the first one is going to be
encryption in flights.
Then, why would we want even encryption in flights?
Well, we want encryption in flight because
if I send a very sensitive secret,
for example, my credit card to a server,
to make a payment online,
I want to make sure that no one else, on the way,
where my network packet is going to travel,
can see my credit card number.
So I want to make sure that
when I make a payment online,
I have that green lock,
I have that HTTPS website which guarantees me,
that it is an SSL enabled website,
and I will get encryption in flight.
And so when you have encryption in flight,
the data will be encrypted
before I sent it,
and then the server will be decrypting it
after receiving it.
But, only myself and the server
know how to do these things.
Now the SSL certificates are what's going to
help with the encryption, and so another way to
see it is HTTPS.
So anytime we've been dealing
with with an Amazon service,
and it had an HTTPS endpoint,
that guaranteed us that it was encryption in flight.
And now the whole web, almost the whole web,
needs to run on SSL and HTTPS.
Basically, when you have this enabled,
you're protected against
the 'man in the middle' attack.
And so, this guarantees that,
when you have that green lock,
and that the server certificate is valid,
that no one can retrieve your sensitive information.
So let's do a quick example.
Here is us, and we want to talk to
an HTTP website on AWS;
could be DynamoDB,
could be whatever we want.
And then what we're going to do,
is that we're going to have add the super secret data,
we're going to encrypt it with SSL encryption,
and send it over the network,
and then the website will receive the data,
and know how to decrypt it.
Very, very simple; the idea of it,
but the execution is not as easy,
so this is how much I'll give you.
The good news is that all programming languages
know how to do SSL encryption and decryption,
and already do this for you,
so you don't have to worry about anything.
This is not something you have to deal with directly.
The second thing is going to be called
server side encryption at rest.
And so that is when the data is encrypted,
after being received by the server.
So before that, the server was receiving data,
decrypting it, and using it in its decrypted form.
Here, the server is going to
store the data on its disk,
and so we need to know that the server
is storing the data in an encrypted form.
Because, in case the server gets hijacked
by someone else,
we don't want that someone else
to be able to decrypt that data.
And so the data will be decrypted before being sent
back to our client.
So, thanks to a key, usually called a data key,
then that data is going to be stored
in an encrypted form,
and the encryption and decryption keys
must be managed somewhere,
usually called a KMS, or key management service,
and the server must have the right to talk to
that key management service.
So here's our object, and we're going to
transfer it, for example, to EBS.
So it's gonna be transferred over whatever mechanism,
and EBS will use a data key,
and using a data key will perform encryption of that data,
and now it's stored in an encrypted form,
and then the day we need to retrieve the data
for whatever reason, then EBS,
the AWS service, will do decryption for us
using the data key again,
and we'll get the de-encrypted data,
and back to us over at HTTP, HTTPS, for example.
So this is how server side encryption works,
and as you can see, the server side itself
of the service, manages the encryption
and the decryption, and uses a data key
it has access to.
So this is, for server side encryption at rest.
And we've seen that many AWS services
do use that encryption at rest.
Now let's talk about client side encryption.
In client side encryption, the data will be
encrypted by the client, and the client is us.
The server will never be able to decrypt that data.
The data will then be decrypted by a receiving client.
So all in all, the data is just stored on the server,
but the server doesn't know what the data means.
And the server, as best practice,
should never be able to decrypt the data anyway.
And for this, we could leverage something called
envelope encryption, but I have a whole lecture on this
later on, because this is pretty advanced,
but the example asks you about envelope encryption,
so for now, let's just do an abstraction of it.
So we have our object, and on our client,
we're going to use a data key,
and we're going to encrypt our data client side.
So we perform encryption with that data key.
Now we send that data to any store of data we want;
could be FTP, could be S3,
could be whatever you want really.
You put your data wherever you want,
say Amazon or somewhere else.
And then, when you receive it,
your client will receive an encrypted object,
and if it has access to the data key,
if it can manage to retrieve
the data key from somewhere,
then it will be able to perform a decryption,
and get the decrypted object as a result.
So as you can see now, the encryption happens
client side.
The server, the data store, does not know how
to decrypt or encrypt the data,
it just receives encrypted data.
And so that's quite secure as well.
So here are the three kinds of encryption
you can get, overall, except envelope encryption
that we'll show you later on.
So this is not using any KMS just yet.
This is just an abstraction of how encryption works.
I know this may be a little bit simplified,
but hopefully that clears up what encryption is,
and in the next lecture, we're going to
do a deep dive into KMS.