WEBVTT 00:00:01.140 --> 00:00:04.270 Certainly one of the most important and valuable tools we 00:00:04.270 --> 00:00:07.050 have for protecting data is encryption. 00:00:07.840 --> 00:00:12.790 Let's take a look at the things we need to consider as cloud security 00:00:12.790 --> 00:00:16.660 professionals when it comes to encryption and key management. 00:00:18.540 --> 00:00:22.230 The protection of data through encryption accomplishes many or 00:00:22.230 --> 00:00:26.610 realizes many benefits, the confidentiality of the data, 00:00:26.620 --> 00:00:32.580 both in transmission and stored, as well as the integrity of the data. 00:00:32.580 --> 00:00:38.100 It manages to ensure that we do not break the law by granting a person 00:00:38.110 --> 00:00:41.050 access to something they should not see. 00:00:41.640 --> 00:00:43.170 And in that way, 00:00:43.180 --> 00:00:47.890 even if a person was to get access to an encrypted file, it would 00:00:47.890 --> 00:00:51.060 not give them access to the information itself. 00:00:52.140 --> 00:00:57.270 One of the things also we've realized with asymmetric encryption is the ability 00:00:57.270 --> 00:01:02.280 to prove who we are talking to. Through things like digital signatures, for 00:01:02.280 --> 00:01:08.830 example, we can establish authentication and in that way also nonrepudiation. 00:01:08.830 --> 00:01:14.800 With asymmetric, we can make sure that only the intended party can open the 00:01:14.800 --> 00:01:20.900 message by using that person's public key, and we can prove who sent the message 00:01:20.910 --> 00:01:23.150 by using our own private key. 00:01:24.440 --> 00:01:28.150 Symmetric encryption has been around for thousands of years. 00:01:28.150 --> 00:01:33.490 We have examples of symmetric back from ancient Sumeria, Greece, 00:01:33.490 --> 00:01:38.930 Rome, and so on. And it provides excellent protection of data, 00:01:38.930 --> 00:01:43.960 both in storage and transmission, and it's relatively fast. When 00:01:43.960 --> 00:01:46.170 we compare it to asymmetric, 00:01:46.270 --> 00:01:51.160 we know that symmetric encryption operates relatively quickly and 00:01:51.160 --> 00:01:54.760 therefore is better when we are going to encrypt bulk data. 00:01:55.840 --> 00:02:01.710 But symmetric encryption has some benefits and disadvantages. While 00:02:01.710 --> 00:02:06.620 the benefits are excellent confidentiality and, of course, speed, the 00:02:06.620 --> 00:02:11.780 disadvantages are the fact that we need to share a key with another 00:02:11.780 --> 00:02:17.760 person. And as we often say, any shared secret is no longer a secret. 00:02:18.840 --> 00:02:22.480 So we need to ensure we have good key management. 00:02:22.490 --> 00:02:26.660 We could call it careful key management in the way that we 00:02:26.660 --> 00:02:31.060 create, store, and distribute keys as well. 00:02:32.340 --> 00:02:36.920 One of the factors that is affecting encryption in the cloud 00:02:37.110 --> 00:02:42.250 is the possession of the keys. Who holds the keys? If we're 00:02:42.250 --> 00:02:44.130 dealing with Software as a Service, 00:02:44.130 --> 00:02:47.290 the challenge we have is that the Software as a 00:02:47.290 --> 00:02:50.360 Service provider has all of the keys. 00:02:50.840 --> 00:02:55.830 They manage the encryption out to the end user over the network. 00:02:56.260 --> 00:03:01.060 They also manage the encryption of the stored data on their systems. 00:03:01.840 --> 00:03:05.340 And while those would be two different types of encryption, 00:03:05.400 --> 00:03:09.920 we have seen cases where cloud service providers were using the same 00:03:09.920 --> 00:03:13.860 encryption key for stored data for multiple clients. 00:03:15.340 --> 00:03:17.760 When we encrypt in transmission, 00:03:18.140 --> 00:03:21.970 we quite often use a hybrid of both symmetric and asymmetric 00:03:21.970 --> 00:03:25.420 encryption. And when we encrypt in storage, 00:03:25.420 --> 00:03:31.740 it's almost always symmetric encryption. In Platform as a Service, 00:03:31.740 --> 00:03:36.750 the keys can be controlled by either party or both. 00:03:37.240 --> 00:03:37.930 For example, 00:03:37.930 --> 00:03:43.820 the cloud consumer controls the application and can therefore control the keys 00:03:43.820 --> 00:03:49.920 used to encrypt the data in both transmission and storage. But we also see cases 00:03:49.930 --> 00:03:55.820 where the cloud service provider is providing value added benefits and may also 00:03:55.820 --> 00:04:02.370 have access to encryption keys, and therefore could actually see the data of the 00:04:02.370 --> 00:04:08.370 cloud consumer. In the case of Platform as a Service, we do the same as 00:04:08.370 --> 00:04:15.940 symmetric. We use hybrid usually for transmission and symmetric encryption just 00:04:15.940 --> 00:04:16.860 for storage. 00:04:17.839 --> 00:04:20.860 We can also encrypt within the application. 00:04:21.440 --> 00:04:26.160 This is often better if something is automatically encrypted whenever 00:04:26.160 --> 00:04:30.030 it's in the application such as, say, a payment card number, for 00:04:30.030 --> 00:04:34.280 example. When we look at encrypting in a database, 00:04:34.280 --> 00:04:38.760 we can encrypt either the whole database or individual fields, 00:04:39.440 --> 00:04:43.900 and this, again, depends on how the deployment is set up as to 00:04:43.900 --> 00:04:46.460 who actually has access to the keys. 00:04:47.040 --> 00:04:50.790 It could be that the cloud service provider is using some of the 00:04:50.790 --> 00:04:54.390 native encryption within the database that would actually give 00:04:54.390 --> 00:04:56.460 them access to the keys as well. 00:04:57.340 --> 00:05:01.860 The idea is that we want to make encryption almost transparent. 00:05:02.240 --> 00:05:05.590 People don't even realize that what they're doing is encrypted, 00:05:05.810 --> 00:05:08.830 and, of course, we see that with most of our web applications 00:05:08.830 --> 00:05:13.600 today. They switch over to, say, a TLS connection without the 00:05:13.600 --> 00:05:15.360 user even being aware of it. 00:05:16.640 --> 00:05:20.480 It is often recommended to use the built in or native 00:05:20.480 --> 00:05:22.800 encryption in a lot of our systems. 00:05:23.340 --> 00:05:27.750 It's often very robust and, of course, very effective in that way. 00:05:28.340 --> 00:05:32.960 And it could be better than trying to just develop our own solution, which 00:05:32.960 --> 00:05:38.820 would run as an add‑on on top of what's already there. In the case of 00:05:38.820 --> 00:05:44.230 Infrastructure as a Service, this is where the cloud consumer has complete 00:05:44.230 --> 00:05:49.010 control over the keys because they are managing all of the applications and 00:05:49.010 --> 00:05:53.820 platforms, and the cloud service provider is only providing, for example, 00:05:53.820 --> 00:05:54.860 the facilities. 00:05:55.340 --> 00:05:58.440 Now, it could well be that there is encryption on 00:05:58.440 --> 00:06:00.650 the network done by both parties. 00:06:01.340 --> 00:06:06.500 So when we talk about transmission in this case, we could see cases where 00:06:06.510 --> 00:06:09.540 most of the encryption is being done by a consumer, 00:06:09.620 --> 00:06:12.670 but it could also be done, in some cases, by a cloud service 00:06:12.670 --> 00:06:17.400 provider, storage completely controlled using symmetric 00:06:17.400 --> 00:06:19.460 encryption by the cloud consumer. 00:06:21.240 --> 00:06:23.850 So the big thing here is key management. 00:06:24.340 --> 00:06:29.900 We know from Kerckhoff's principle that the only thing we need to do 00:06:29.900 --> 00:06:33.160 to protect encrypted data is to protect the key. 00:06:33.640 --> 00:06:37.360 We don't have to make the algorithm some deep dark secret. 00:06:37.840 --> 00:06:42.530 No, we quite often use common algorithms that everybody else uses as well. 00:06:42.730 --> 00:06:47.650 It certainly makes things more interoperable, but we need to make sure 00:06:47.650 --> 00:06:50.850 that no one gets the key who should not have it. 00:06:51.540 --> 00:06:55.460 But we also have the problem, what happens if we lose a key? 00:06:55.840 --> 00:06:58.640 Well then, we've lost our data. So we need to have some 00:06:58.640 --> 00:07:01.360 type of key recovery scheme as well. 00:07:02.040 --> 00:07:07.650 Maybe we keep our keys with a trusted third party. We would call that 00:07:07.650 --> 00:07:13.200 keeping the key in escrow. The other is to split the key into multiple 00:07:13.200 --> 00:07:18.320 parts, and we store different parts of the key in different locations, so 00:07:18.320 --> 00:07:21.500 hopefully even if one location was compromised, 00:07:21.530 --> 00:07:25.980 the person would not have the entire key to decrypt the information. 00:07:26.300 --> 00:07:31.460 This is often called split knowledge or even multi‑party type of key recovery. 00:07:32.640 --> 00:07:35.360 We combine this very often with dual control. 00:07:35.740 --> 00:07:38.140 It takes two people to do an action. 00:07:38.410 --> 00:07:40.770 Now it could be because we have two people that have 00:07:40.770 --> 00:07:44.190 different parts of the key, or it could be that in order to 00:07:44.190 --> 00:07:46.360 get access to one part of the key, 00:07:46.370 --> 00:07:51.660 you need actually two people to gain access to that secure storage area. 00:07:53.140 --> 00:07:58.400 We've seen for many years the use of hardware security modules, 00:07:58.400 --> 00:08:03.720 or HSMs, to protect keys, the root key of a bank, for example, 00:08:03.720 --> 00:08:06.360 the most valuable thing the bank has. 00:08:06.510 --> 00:08:09.210 If you have the private root key of a bank, 00:08:09.220 --> 00:08:13.310 you have access to all the money they have. Now, for 00:08:13.310 --> 00:08:15.020 many years these were hardware. 00:08:15.020 --> 00:08:19.950 Now they are, of course, software security modules as well, 00:08:19.950 --> 00:08:25.490 but it is a mechanism used to protect the key from any type 00:08:25.490 --> 00:08:27.260 of unauthorized disclosure. 00:08:28.440 --> 00:08:32.850 We might even outsource key management, let somebody else look after 00:08:32.850 --> 00:08:37.350 this for us as part of even an Identity as a Service, or we could say 00:08:37.350 --> 00:08:40.190 here in a case of a public key infrastructure, 00:08:40.429 --> 00:08:45.180 sometimes the public key infrastructure administrator will 00:08:45.180 --> 00:08:47.660 actually have access to private keys. 00:08:48.340 --> 00:08:51.890 This, of course, brings into question things like authenticity and 00:08:51.890 --> 00:08:56.390 nonrepudiation, but the other, of course, is using some type of cloud 00:08:56.390 --> 00:09:01.230 access security broker, or CASB, that actually manages the keys on our 00:09:01.230 --> 00:09:07.950 behalf. When we do asymmetric encryption, asymmetric is primarily used 00:09:07.950 --> 00:09:13.160 for two things, to support symmetric through the distribution or to 00:09:13.160 --> 00:09:14.970 negotiate symmetric keys. 00:09:14.970 --> 00:09:19.620 Diffie Hellman does negotiation, whereas a number of the other 00:09:19.620 --> 00:09:23.050 tools are used to distribute symmetric keys. 00:09:23.840 --> 00:09:27.230 The other thing that asymmetric is really good for are digital 00:09:27.230 --> 00:09:31.970 signatures. A digital signature is created by encrypting the hash of 00:09:31.970 --> 00:09:36.840 a message with the private key of the sender, and that provides 00:09:37.050 --> 00:09:40.060 message authenticity, proof of origin. 00:09:40.440 --> 00:09:46.000 It also prevents replay attacks through timestamps, and it is a very 00:09:46.000 --> 00:09:52.420 good, useful tool in this way to try to support secure communications, 00:09:52.420 --> 00:09:55.950 even with people we can't see face to face. 00:09:56.840 --> 00:10:00.460 The reason we don't use asymmetric to do bulk data 00:10:00.460 --> 00:10:02.750 encryption is it's just too slow. 00:10:03.440 --> 00:10:08.050 Of course, over the next few years we've seen the movement 00:10:08.050 --> 00:10:11.560 towards more and more types of quantum computing, 00:10:12.040 --> 00:10:14.460 which is not the same as quantum cryptography. 00:10:15.240 --> 00:10:20.620 Quantum cryptography is based on fiber and photons, and 00:10:20.620 --> 00:10:23.060 I'm not sure what the future of that is. 00:10:23.740 --> 00:10:26.850 The first couple of implementations of quantum 00:10:26.850 --> 00:10:28.750 cryptography have already been broken. 00:10:29.440 --> 00:10:34.860 But quantum computing very definitely has a tremendous future, 00:10:35.240 --> 00:10:39.350 exponential increase in processing power of our systems. 00:10:40.540 --> 00:10:44.680 And there is reason to believe that within a few years we could see 00:10:44.860 --> 00:10:49.590 that asymmetric encryption is no longer computationally feasible or 00:10:49.590 --> 00:10:55.300 secure because quite simply quantum computing would be able to break or 00:10:55.310 --> 00:10:59.660 then compromise the asymmetric keys. 00:11:01.140 --> 00:11:05.460 The key points review. Encryption is a valuable tool. 00:11:05.940 --> 00:11:11.850 We use it to protect data, but we have to be careful about key management. 00:11:12.540 --> 00:11:17.060 We must train our users and administrators in good practices 00:11:17.060 --> 00:11:20.640 when they're using encryption and, of course, make sure that 00:11:20.640 --> 00:11:22.060 it's correctly configured. 00:11:22.640 --> 00:11:27.940 We've seen the majority of breaches of encrypted data have 00:11:27.940 --> 00:11:31.580 happened not because of a weakness in the algorithm, 00:11:31.650 --> 00:11:34.360 but because of a weakness in the implementation.