WEBVTT 00:00.199 --> 00:03.945 >> Public key infrastructure or PKI. 00:03.945 --> 00:06.930 The learning objectives for this lesson are to explore 00:06.930 --> 00:09.330 how PKI functions and its role, 00:09.330 --> 00:11.865 to define the parts involved with PKI, 00:11.865 --> 00:14.685 and to explore how PKI is implemented and used. 00:14.685 --> 00:17.420 Let's get started. You may remember in 00:17.420 --> 00:20.420 the previous lesson where we discuss the difficulties of 00:20.420 --> 00:23.060 sending symmetric encrypted data to 00:23.060 --> 00:24.860 someone and then supplying 00:24.860 --> 00:26.840 the password to them to decrypt it. 00:26.840 --> 00:28.610 It's very difficult to ensure that 00:28.610 --> 00:30.355 that password is not intercepted, 00:30.355 --> 00:33.640 so asymmetric encryption solves this problem. 00:33.640 --> 00:35.795 It does so by creating a key pair. 00:35.795 --> 00:37.520 The first is the public key they 00:37.520 --> 00:39.200 can be freely given to anyone, 00:39.200 --> 00:40.250 and the second is 00:40.250 --> 00:42.440 the private key which we have to keep secure; 00:42.440 --> 00:46.420 it's used to decrypt messages that have been sent to us. 00:46.420 --> 00:49.995 But this is a key part of how PKI functions, 00:49.995 --> 00:51.530 and I want to make sure you understand 00:51.530 --> 00:52.790 this before we move deeper. 00:52.790 --> 00:55.250 I'm going to use a visual on the next slides to 00:55.250 --> 00:58.920 show you how this process works from start to finish. 00:59.110 --> 01:05.580 We have Alice, and she wants to send a message to Bob. 01:05.580 --> 01:10.050 Bob will send his public key to Alice. 01:10.490 --> 01:12.510 Alice will then use 01:12.510 --> 01:16.075 Bob's public key and encrypt a message to him. 01:16.075 --> 01:19.015 Then she'll send that message directly to Bob. 01:19.015 --> 01:21.330 Bob will take his 01:21.330 --> 01:24.745 private key and decrypt the message and then read it. 01:24.745 --> 01:27.230 This gives you a basic flow of 01:27.230 --> 01:29.750 how asymmetric encryption works. 01:29.750 --> 01:31.160 But these are the key points that 01:31.160 --> 01:32.855 I wanted you to keep in mind. 01:32.855 --> 01:36.410 Public key and private key are a matching pair. 01:36.410 --> 01:38.720 Our public key can be freely given to anyone but 01:38.720 --> 01:41.345 we've got to keep our private key safe and secure. 01:41.345 --> 01:43.880 We can use asymmetric encryption to 01:43.880 --> 01:46.970 digitally sign messages or files and by doing that, 01:46.970 --> 01:49.750 I am proving that I'm the one who did that. 01:49.750 --> 01:54.810 Let's move on into how this connects over to PKI. 01:55.090 --> 01:58.595 Public key infrastructure or PKI are tools 01:58.595 --> 01:59.750 that support not only 01:59.750 --> 02:01.624 encryption and digital certificates, 02:01.624 --> 02:05.195 but also integrity checks and authentication is 02:05.195 --> 02:06.950 a central control over 02:06.950 --> 02:08.780 the digital certificates that can be used 02:08.780 --> 02:10.880 to identify users and services. 02:10.880 --> 02:12.575 Those digital certificates will have 02:12.575 --> 02:15.620 a public key embedded in them and 02:15.620 --> 02:17.840 allows for message signing or 02:17.840 --> 02:20.180 for message integrity and authentication. 02:20.180 --> 02:22.160 When we're signing messages with 02:22.160 --> 02:24.580 a digital certificate or our public key, 02:24.580 --> 02:26.735 we're proving that I'm the one who did this. 02:26.735 --> 02:29.640 That gives us non-repudiation. 02:30.560 --> 02:34.020 Let's talk about some common uses of PKI. 02:34.020 --> 02:36.785 Code signing is a very good example of this. 02:36.785 --> 02:39.800 We have to be able to show that this code that we're 02:39.800 --> 02:43.060 producing it may be an executable or a driver, 02:43.060 --> 02:47.270 are validated by us that we're the ones that did this, 02:47.270 --> 02:48.895 and it is trustworthy. 02:48.895 --> 02:51.320 This is becoming a really big deal 02:51.320 --> 02:52.400 because we need to ensure 02:52.400 --> 02:53.600 that the drivers we're installing, 02:53.600 --> 02:55.130 the executables we're installing, 02:55.130 --> 02:56.750 come from sources that have been 02:56.750 --> 02:59.780 validated and their certificates are 02:59.780 --> 03:02.080 trusted by a certificate authority and 03:02.080 --> 03:05.460 that certificate authority itself is a trusted CA. 03:05.460 --> 03:07.180 If you remember Stuxnet that I 03:07.180 --> 03:08.815 discussed in a previous lesson, 03:08.815 --> 03:11.305 they use stolen digital certificates 03:11.305 --> 03:13.990 to install malware onto systems, 03:13.990 --> 03:17.350 and they did this by signing drivers that 03:17.350 --> 03:20.710 Microsoft when Windows saw these particular drivers 03:20.710 --> 03:22.780 had been signed by a certificate 03:22.780 --> 03:24.910 that was accepted they allowed those drivers to 03:24.910 --> 03:26.980 be installed directly onto the system without even 03:26.980 --> 03:29.920 taking it further to check them out or to block that. 03:29.920 --> 03:32.020 By doing that they just snuck right past 03:32.020 --> 03:34.450 all the defenses and that really allowed 03:34.450 --> 03:39.900 for the virus to first begin its exploitation part, 03:39.900 --> 03:41.760 but to really spread further. 03:41.760 --> 03:44.110 You can see the importance of making sure 03:44.110 --> 03:46.765 that we're assigning our software 03:46.765 --> 03:48.740 or our code because it's 03:48.740 --> 03:50.420 such a key part to ensuring 03:50.420 --> 03:52.730 we're not installing bad things in there. 03:52.730 --> 03:54.560 Now we can't stop it if a certificate has 03:54.560 --> 03:56.720 stolen in the case of Stuxnet, 03:56.720 --> 03:58.085 but we can at least prevent 03:58.085 --> 04:02.030 the easier attacks by installing drivers or apps on 04:02.030 --> 04:04.670 our devices by not allowing 04:04.670 --> 04:08.430 them to be installed from sources that are not trusted. 04:09.940 --> 04:14.660 A digital certificate is a public assertion of identity. 04:14.660 --> 04:16.340 I'm saying this is me, 04:16.340 --> 04:19.565 and my digital certificate has a public key in that. 04:19.565 --> 04:21.890 Not only that, my digital certificate has 04:21.890 --> 04:24.410 been validated by a certificate authority. 04:24.410 --> 04:26.075 That CA has said yes, 04:26.075 --> 04:27.410 we know who this person is 04:27.410 --> 04:29.030 they are who they say they are, 04:29.030 --> 04:31.915 it is safe to send a message to him. 04:31.915 --> 04:35.940 We can not only use this for sending messages, 04:35.940 --> 04:38.075 or encrypting messages, or signing messages, 04:38.075 --> 04:40.820 but we can also use it for encrypting web traffic. 04:40.820 --> 04:43.280 Your browser has its own digital certificate and then 04:43.280 --> 04:46.115 when we're going to a website via HTTPS, 04:46.115 --> 04:47.930 we're using our digital certificate 04:47.930 --> 04:49.940 and the site's digital certificate to 04:49.940 --> 04:53.570 negotiate encryption to ensure 04:53.570 --> 04:56.045 that the traffic is encrypted back and forth. 04:56.045 --> 04:57.920 If we would have a third party 04:57.920 --> 04:58.940 that jumped in there and put 04:58.940 --> 05:02.760 a bad certificate on that web server, 05:02.760 --> 05:04.430 then they would be able to intercept 05:04.430 --> 05:06.515 that traffic so we have to make sure that 05:06.515 --> 05:08.970 our web servers that we're 05:08.970 --> 05:11.585 browsing to or if we have our servers and our own company 05:11.585 --> 05:13.370 that we have valid digital 05:13.370 --> 05:14.540 certificates that are in place to 05:14.540 --> 05:17.705 validate who we are as a web server, 05:17.705 --> 05:21.020 or end users need to make sure that when they're going to 05:21.020 --> 05:23.690 different websites that were certificates 05:23.690 --> 05:27.540 we see are valid and match the website we're going to. 05:28.720 --> 05:31.430 We can also use our digital certificates 05:31.430 --> 05:33.020 for secure authentication. 05:33.020 --> 05:35.405 We need to be able to ensure that 05:35.405 --> 05:37.520 two parties or two entities can 05:37.520 --> 05:39.875 authenticate to each other in a secure way. 05:39.875 --> 05:43.225 Sometimes this may involve multifactor authentication. 05:43.225 --> 05:45.469 We can also use device certificates, 05:45.469 --> 05:47.855 or the device itself has its own certificate, 05:47.855 --> 05:50.915 and they can authenticate to another device or service. 05:50.915 --> 05:52.790 A good example of this would be 05:52.790 --> 05:54.800 if you had a remote user who was 05:54.800 --> 05:56.045 wanting to connect via 05:56.045 --> 05:59.135 your corporate VPN back to the corporate network. 05:59.135 --> 06:01.190 Maybe it's not enough just to have a password 06:01.190 --> 06:03.455 because the password could be guessed or cracked. 06:03.455 --> 06:04.970 You may want them to use something 06:04.970 --> 06:07.140 like a smartcard, for example, 06:07.140 --> 06:08.870 and that smartcard would have 06:08.870 --> 06:10.640 a digital certificate stored 06:10.640 --> 06:12.350 on a chip that's on that card, 06:12.350 --> 06:14.585 and the user would plug their card in, 06:14.585 --> 06:16.280 and then they have to activate 06:16.280 --> 06:18.380 it by using their PIN code. 06:18.380 --> 06:21.590 Now we've established a multifactor authentication system 06:21.590 --> 06:23.990 for this user to connect to our VPN. 06:23.990 --> 06:26.420 They first had to have a password, 06:26.420 --> 06:28.415 they add to use their smartcard, 06:28.415 --> 06:30.470 and then their smartcard to be activated, 06:30.470 --> 06:31.580 had to have a pin code. 06:31.580 --> 06:33.860 That's multifactor to ensure that we have 06:33.860 --> 06:37.560 the right person authenticating to our VPN server. 06:38.480 --> 06:42.285 We can also use PKI automation support. 06:42.285 --> 06:45.560 When our certificates are used for authentication, 06:45.560 --> 06:47.490 we're logging a lot of events. 06:47.490 --> 06:50.390 Sometimes these are going to be denials, 06:50.390 --> 06:53.540 and sometimes it's going to be the granting of access. 06:53.540 --> 06:55.160 But either way we can set up 06:55.160 --> 06:57.110 different triggers to happen based 06:57.110 --> 06:58.970 on certain thresholds on 06:58.970 --> 07:00.845 the actions that we want it to happen. 07:00.845 --> 07:02.780 For example, with our VPN user 07:02.780 --> 07:04.070 that we discussed earlier, 07:04.070 --> 07:05.945 maybe we don't want to allow 07:05.945 --> 07:08.195 anyone to connect to our VPN after 07:08.195 --> 07:10.130 midnight or we don't want to 07:10.130 --> 07:13.235 allow anyone to connect before a certain time. 07:13.235 --> 07:15.005 When those authentications come in, 07:15.005 --> 07:16.340 even if they're valid, 07:16.340 --> 07:19.010 we can have an automated playbook that will go into 07:19.010 --> 07:21.740 effect to ensure that certain actions 07:21.740 --> 07:24.800 are taken on those authentications based on 07:24.800 --> 07:29.450 the steps or actions that we have set up ourselves. 07:29.450 --> 07:31.595 This is really helpful 07:31.595 --> 07:33.905 when we're looking for malicious events. 07:33.905 --> 07:35.420 We want to be able to respond to 07:35.420 --> 07:37.100 those as quickly as possible. 07:37.100 --> 07:38.495 It's a lot easier to have 07:38.495 --> 07:40.670 an automated process that performs 07:40.670 --> 07:43.550 certain specified actions rather than having someone 07:43.550 --> 07:44.870 sitting there looking for 07:44.870 --> 07:48.040 events and then having them respond. 07:48.040 --> 07:51.830 We could even take this a step further that if 07:51.830 --> 07:55.070 someone successfully authenticates to our network, 07:55.070 --> 07:57.850 we want to make sure that their device even reaches 07:57.850 --> 08:01.420 a certain standard before it's allowed to gain access. 08:01.420 --> 08:02.710 We may want to make sure that they have 08:02.710 --> 08:04.330 a certain patch level or they 08:04.330 --> 08:08.390 have a specific anti-malware products in place, 08:08.760 --> 08:12.160 and we want to put all of that in 08:12.160 --> 08:13.930 our automation so that even 08:13.930 --> 08:16.075 if someone successfully authenticates, 08:16.075 --> 08:19.000 if their device doesn't meet a certain standard or 08:19.000 --> 08:20.635 our corporate policy that 08:20.635 --> 08:23.510 we're not going to allow them to authenticate. 08:24.920 --> 08:27.285 Federated PKI. 08:27.285 --> 08:30.895 This is where we have two independent PKI hierarchies 08:30.895 --> 08:34.000 that each support their own trust domains. 08:34.000 --> 08:36.315 They have their own root certificate authorities 08:36.315 --> 08:37.755 but they trust each other. 08:37.755 --> 08:39.125 By doing this, 08:39.125 --> 08:41.965 the users in the first group 08:41.965 --> 08:44.910 automatically will trust the users in the second group. 08:44.910 --> 08:48.190 This greatly expands the ability for organizations 08:48.190 --> 08:49.720 to trust each other without 08:49.720 --> 08:51.945 having to set up complex policies. 08:51.945 --> 08:54.890 In a Federated PKI situation 08:54.890 --> 08:58.240 you make sure that both of the organizations that 08:58.240 --> 09:00.190 are involved have a common set of 09:00.190 --> 09:02.560 policies there so that you're not giving 09:02.560 --> 09:07.290 too many levels of trust away too easily, 09:07.290 --> 09:08.965 you want to make sure that your policies 09:08.965 --> 09:10.630 match each other. 09:10.630 --> 09:12.250 I also wanted to clear up that it 09:12.250 --> 09:14.090 doesn't have to be just two organizations. 09:14.090 --> 09:15.820 They can be any number of organizations, 09:15.820 --> 09:17.690 but for sake of an example we're 09:17.690 --> 09:19.250 discussing two different organizations 09:19.250 --> 09:20.380 that trust each other, 09:20.380 --> 09:23.180 but you can have as many as you want it on 09:23.180 --> 09:24.730 a global scale and 09:24.730 --> 09:28.160 all those organizations will be able to trust each other. 09:29.030 --> 09:31.955 Let's summarize. We went over 09:31.955 --> 09:35.270 asymmetric encryption and public key infrastructure. 09:35.270 --> 09:36.710 We also went over the components of 09:36.710 --> 09:39.320 PKI and certificate authorities. 09:39.320 --> 09:41.930 We discussed the common usages of PKI, 09:41.930 --> 09:45.350 Federated PKI, and secure authentication. 09:45.350 --> 09:49.650 Let's do some example questions. Question 1. 09:49.650 --> 09:52.735 True or false, in public key encryption, 09:52.735 --> 09:55.280 the receiver's private key is used to encrypt 09:55.280 --> 09:58.695 messages to them/ false. 09:58.695 --> 10:04.605 The receiver's public key is used. Question 2. 10:04.605 --> 10:08.720 Blank is a set of independent PKI hierarchies that 10:08.720 --> 10:13.650 trust each other. Federated PKI. 10:13.650 --> 10:17.930 Question 3. This is used for PKI that involves 10:17.930 --> 10:22.500 software proving its authenticity as safe to be used. 10:23.150 --> 10:27.750 Code signing. Question 4. 10:27.750 --> 10:29.360 A blank will validate 10:29.360 --> 10:33.360 certificates so that their authenticity can be proven. 10:33.530 --> 10:36.380 Certificate authority. I hope 10:36.380 --> 10:37.610 this lesson was helpful for you 10:37.610 --> 10:39.690 , and I'll see you in the next one.