Certainly one of the most important and valuable tools we
have for protecting data is encryption.
Let's take a look at the things we need to consider as cloud security
professionals when it comes to encryption and key management.
The protection of data through encryption accomplishes many or
realizes many benefits, the confidentiality of the data,
both in transmission and stored, as well as the integrity of the data.
It manages to ensure that we do not break the law by granting a person
access to something they should not see.
And in that way,
even if a person was to get access to an encrypted file, it would
not give them access to the information itself.
One of the things also we've realized with asymmetric encryption is the ability
to prove who we are talking to. Through things like digital signatures, for
example, we can establish authentication and in that way also nonrepudiation.
With asymmetric, we can make sure that only the intended party can open the
message by using that person's public key, and we can prove who sent the message
by using our own private key.
Symmetric encryption has been around for thousands of years.
We have examples of symmetric back from ancient Sumeria, Greece,
Rome, and so on. And it provides excellent protection of data,
both in storage and transmission, and it's relatively fast. When
we compare it to asymmetric,
we know that symmetric encryption operates relatively quickly and
therefore is better when we are going to encrypt bulk data.
But symmetric encryption has some benefits and disadvantages. While
the benefits are excellent confidentiality and, of course, speed, the
disadvantages are the fact that we need to share a key with another
person. And as we often say, any shared secret is no longer a secret.
So we need to ensure we have good key management.
We could call it careful key management in the way that we
create, store, and distribute keys as well.
One of the factors that is affecting encryption in the cloud
is the possession of the keys. Who holds the keys? If we're
dealing with Software as a Service,
the challenge we have is that the Software as a
Service provider has all of the keys.
They manage the encryption out to the end user over the network.
They also manage the encryption of the stored data on their systems.
And while those would be two different types of encryption,
we have seen cases where cloud service providers were using the same
encryption key for stored data for multiple clients.
When we encrypt in transmission,
we quite often use a hybrid of both symmetric and asymmetric
encryption. And when we encrypt in storage,
it's almost always symmetric encryption. In Platform as a Service,
the keys can be controlled by either party or both.
For example,
the cloud consumer controls the application and can therefore control the keys
used to encrypt the data in both transmission and storage. But we also see cases
where the cloud service provider is providing value added benefits and may also
have access to encryption keys, and therefore could actually see the data of the
cloud consumer. In the case of Platform as a Service, we do the same as
symmetric. We use hybrid usually for transmission and symmetric encryption just
for storage.
We can also encrypt within the application.
This is often better if something is automatically encrypted whenever
it's in the application such as, say, a payment card number, for
example. When we look at encrypting in a database,
we can encrypt either the whole database or individual fields,
and this, again, depends on how the deployment is set up as to
who actually has access to the keys.
It could be that the cloud service provider is using some of the
native encryption within the database that would actually give
them access to the keys as well.
The idea is that we want to make encryption almost transparent.
People don't even realize that what they're doing is encrypted,
and, of course, we see that with most of our web applications
today. They switch over to, say, a TLS connection without the
user even being aware of it.
It is often recommended to use the built in or native
encryption in a lot of our systems.
It's often very robust and, of course, very effective in that way.
And it could be better than trying to just develop our own solution, which
would run as an add‑on on top of what's already there. In the case of
Infrastructure as a Service, this is where the cloud consumer has complete
control over the keys because they are managing all of the applications and
platforms, and the cloud service provider is only providing, for example,
the facilities.
Now, it could well be that there is encryption on
the network done by both parties.
So when we talk about transmission in this case, we could see cases where
most of the encryption is being done by a consumer,
but it could also be done, in some cases, by a cloud service
provider, storage completely controlled using symmetric
encryption by the cloud consumer.
So the big thing here is key management.
We know from Kerckhoff's principle that the only thing we need to do
to protect encrypted data is to protect the key.
We don't have to make the algorithm some deep dark secret.
No, we quite often use common algorithms that everybody else uses as well.
It certainly makes things more interoperable, but we need to make sure
that no one gets the key who should not have it.
But we also have the problem, what happens if we lose a key?
Well then, we've lost our data. So we need to have some
type of key recovery scheme as well.
Maybe we keep our keys with a trusted third party. We would call that
keeping the key in escrow. The other is to split the key into multiple
parts, and we store different parts of the key in different locations, so
hopefully even if one location was compromised,
the person would not have the entire key to decrypt the information.
This is often called split knowledge or even multi‑party type of key recovery.
We combine this very often with dual control.
It takes two people to do an action.
Now it could be because we have two people that have
different parts of the key, or it could be that in order to
get access to one part of the key,
you need actually two people to gain access to that secure storage area.
We've seen for many years the use of hardware security modules,
or HSMs, to protect keys, the root key of a bank, for example,
the most valuable thing the bank has.
If you have the private root key of a bank,
you have access to all the money they have. Now, for
many years these were hardware.
Now they are, of course, software security modules as well,
but it is a mechanism used to protect the key from any type
of unauthorized disclosure.
We might even outsource key management, let somebody else look after
this for us as part of even an Identity as a Service, or we could say
here in a case of a public key infrastructure,
sometimes the public key infrastructure administrator will
actually have access to private keys.
This, of course, brings into question things like authenticity and
nonrepudiation, but the other, of course, is using some type of cloud
access security broker, or CASB, that actually manages the keys on our
behalf. When we do asymmetric encryption, asymmetric is primarily used
for two things, to support symmetric through the distribution or to
negotiate symmetric keys.
Diffie Hellman does negotiation, whereas a number of the other
tools are used to distribute symmetric keys.
The other thing that asymmetric is really good for are digital
signatures. A digital signature is created by encrypting the hash of
a message with the private key of the sender, and that provides
message authenticity, proof of origin.
It also prevents replay attacks through timestamps, and it is a very
good, useful tool in this way to try to support secure communications,
even with people we can't see face to face.
The reason we don't use asymmetric to do bulk data
encryption is it's just too slow.
Of course, over the next few years we've seen the movement
towards more and more types of quantum computing,
which is not the same as quantum cryptography.
Quantum cryptography is based on fiber and photons, and
I'm not sure what the future of that is.
The first couple of implementations of quantum
cryptography have already been broken.
But quantum computing very definitely has a tremendous future,
exponential increase in processing power of our systems.
And there is reason to believe that within a few years we could see
that asymmetric encryption is no longer computationally feasible or
secure because quite simply quantum computing would be able to break or
then compromise the asymmetric keys.
The key points review. Encryption is a valuable tool.
We use it to protect data, but we have to be careful about key management.
We must train our users and administrators in good practices
when they're using encryption and, of course, make sure that
it's correctly configured.
We've seen the majority of breaches of encrypted data have
happened not because of a weakness in the algorithm,
but because of a weakness in the implementation.