WEBVTT 1 00:00:00.000 --> 00:00:02.430 In this lesson, we will learn 2 00:00:02.430 --> 00:00:07.430 about public key infrastructure or PKI issues. 3 00:00:07.710 --> 00:00:10.770 PKI Issues are problems related 4 00:00:10.770 --> 00:00:14.100 to the management, deployment, and functioning 5 00:00:14.100 --> 00:00:16.680 of the public key infrastructure. 6 00:00:16.680 --> 00:00:20.160 PKI issues undermine the security 7 00:00:20.160 --> 00:00:24.420 of encrypted communications and digital certificates, 8 00:00:24.420 --> 00:00:28.770 and can include misconfigured certificate authorities, 9 00:00:28.770 --> 00:00:33.770 expired or improperly issued certificates and challenges 10 00:00:33.900 --> 00:00:36.210 in certificate revocation 11 00:00:36.210 --> 00:00:40.140 and improper key management or distribution. 12 00:00:40.140 --> 00:00:44.070 Each of these PKI issues can lead to failures 13 00:00:44.070 --> 00:00:48.750 in establishing trust between communicating parties. 14 00:00:48.750 --> 00:00:51.690 Additionally, improper key management 15 00:00:51.690 --> 00:00:53.706 or distribution can result 16 00:00:53.706 --> 00:00:57.810 in unauthorized access or data breaches 17 00:00:57.810 --> 00:01:02.310 as keys may be compromised or used incorrectly. 18 00:01:02.310 --> 00:01:03.720 Let's learn more about 19 00:01:03.720 --> 00:01:07.407 certificate authority misconfigurations, expired 20 00:01:07.407 --> 00:01:11.415 or improperly issued certificates, challenges 21 00:01:11.415 --> 00:01:16.290 in certificate revocation and improper key management 22 00:01:16.290 --> 00:01:17.970 or distribution. 23 00:01:17.970 --> 00:01:21.300 First, we have a certificate authority 24 00:01:21.300 --> 00:01:24.450 or CA misconfigurations. 25 00:01:24.450 --> 00:01:27.060 A certificate authority is responsible 26 00:01:27.060 --> 00:01:31.091 for issuing digital certificates that verify the identity 27 00:01:31.091 --> 00:01:36.090 of users, devices, or organizations. 28 00:01:36.090 --> 00:01:40.320 When a CA is misconfigured, it may issue certificates 29 00:01:40.320 --> 00:01:43.290 improperly or to the wrong parties. 30 00:01:43.290 --> 00:01:48.000 For example, if a CA inadvertently issues a certificate 31 00:01:48.000 --> 00:01:52.734 to an unauthorized user, that user could use the certificate 32 00:01:52.734 --> 00:01:55.950 to impersonate a legitimate party. 33 00:01:55.950 --> 00:01:59.446 This could result in serious security breaches, such 34 00:01:59.446 --> 00:02:04.446 as unauthorized access to sensitive data or systems. 35 00:02:04.950 --> 00:02:09.950 Another example of CA misconfiguration is when a CAs root 36 00:02:10.650 --> 00:02:15.210 or intermediate certificate is not properly secured. 37 00:02:15.210 --> 00:02:19.470 If attackers gain access to the CAs private key, 38 00:02:19.470 --> 00:02:22.200 they could create fraudulent certificates 39 00:02:22.200 --> 00:02:24.030 that appear legitimate, 40 00:02:24.030 --> 00:02:26.790 undermining the entire trust structure 41 00:02:26.790 --> 00:02:29.250 of the public key infrastructure. 42 00:02:29.250 --> 00:02:32.215 This can allow malicious actors to conduct 43 00:02:32.215 --> 00:02:34.987 on path attacks, intercepting 44 00:02:34.987 --> 00:02:39.987 and decrypting encrypted communications between two parties. 45 00:02:40.170 --> 00:02:41.940 An attacker with access 46 00:02:41.940 --> 00:02:44.255 to a compromised certificate authority 47 00:02:44.255 --> 00:02:49.230 or CA could even issue themselves a certificate 48 00:02:49.230 --> 00:02:53.310 for a trusted website such as a bank and use it 49 00:02:53.310 --> 00:02:57.180 to steal credentials or financial information. 50 00:02:57.180 --> 00:03:02.180 So, a CA properly securing itself enables maintaining trust 51 00:03:03.360 --> 00:03:05.610 in digital certificates. 52 00:03:05.610 --> 00:03:08.580 In enterprise environments, organizations 53 00:03:08.580 --> 00:03:13.359 often issue their own internal certificates and even choose 54 00:03:13.359 --> 00:03:18.030 to become their own internal root certificate authorities. 55 00:03:18.030 --> 00:03:21.481 This means the organization is responsible for issuing 56 00:03:21.481 --> 00:03:25.982 and managing digital certificates that verify the identity 57 00:03:25.982 --> 00:03:30.840 of users, devices, and other internal systems. 58 00:03:30.840 --> 00:03:34.920 While this approach can streamline internal operations 59 00:03:34.920 --> 00:03:38.430 and reduce reliance on external CAs, it 60 00:03:38.430 --> 00:03:42.660 also brings the importance of CA configuration 61 00:03:42.660 --> 00:03:46.170 and control to the organizational level. 62 00:03:46.170 --> 00:03:49.710 Any misconfiguration or security flaw 63 00:03:49.710 --> 00:03:53.340 in the enterprise's internal certificate authority 64 00:03:53.340 --> 00:03:58.340 or CA could lead to improper issuance of certificates 65 00:03:58.440 --> 00:04:02.490 or even compromise the entire network security. 66 00:04:02.490 --> 00:04:07.230 So to mitigate the risks of CA misconfiguration 67 00:04:07.230 --> 00:04:08.790 in an enterprise acting 68 00:04:08.790 --> 00:04:13.790 as its own CA, robust security controls must be in place. 69 00:04:14.670 --> 00:04:18.300 These include properly configuring the CA 70 00:04:18.300 --> 00:04:21.270 or certificate authority infrastructure, 71 00:04:21.270 --> 00:04:25.500 securing private keys, using hardware security modules, 72 00:04:25.500 --> 00:04:29.370 and regularly auditing the CA's activities. 73 00:04:29.370 --> 00:04:31.043 Multi-factor authentication 74 00:04:31.043 --> 00:04:35.329 and strict access controls should be enforced to ensure 75 00:04:35.329 --> 00:04:39.121 that only authorized personnel could access 76 00:04:39.121 --> 00:04:42.420 and manage the CA infrastructure. 77 00:04:42.420 --> 00:04:43.860 By carefully managing 78 00:04:43.860 --> 00:04:47.850 and securing the CA, enterprises can ensure 79 00:04:47.850 --> 00:04:51.237 that their internal, public key infrastructure remains 80 00:04:51.237 --> 00:04:53.970 reliable and trusted. 81 00:04:53.970 --> 00:04:57.988 On a larger scale, external root CAs are responsible 82 00:04:57.988 --> 00:05:00.360 for the same things. 83 00:05:00.360 --> 00:05:05.360 Second, we have expired or improperly issued certificates. 84 00:05:05.970 --> 00:05:09.960 Digital certificates have a validity period, 85 00:05:09.960 --> 00:05:11.940 and once they expire, 86 00:05:11.940 --> 00:05:14.850 they're no longer considered trustworthy. 87 00:05:14.850 --> 00:05:17.710 If a certificate expires and is not renewed 88 00:05:17.710 --> 00:05:21.030 in time, users will be unable 89 00:05:21.030 --> 00:05:25.320 to establish secure connections via that certificate. 90 00:05:25.320 --> 00:05:29.730 For example, if a company's website certificate expires 91 00:05:29.730 --> 00:05:32.340 and is not renewed, visitors 92 00:05:32.340 --> 00:05:34.560 to the site will see a warning message 93 00:05:34.560 --> 00:05:37.260 that the connection is not secure. 94 00:05:37.260 --> 00:05:39.720 This could lead to lost business 95 00:05:39.720 --> 00:05:42.944 as users may be justifiably hesitant to proceed 96 00:05:42.944 --> 00:05:46.230 without a secure connection. 97 00:05:46.230 --> 00:05:50.730 Improperly issued certificates can also cause problems. 98 00:05:50.730 --> 00:05:54.091 If a certificate is issued without proper validation 99 00:05:54.091 --> 00:05:57.420 of the requesting party's identity, 100 00:05:57.420 --> 00:06:00.900 the certificate could be used by malicious actors 101 00:06:00.900 --> 00:06:04.230 to impersonate a legitimate organization. 102 00:06:04.230 --> 00:06:08.490 This could lead to phishing attacks or other forms of fraud. 103 00:06:08.490 --> 00:06:11.670 For example, if a certificate authority 104 00:06:11.670 --> 00:06:15.879 or CA issues a certificate to someone who falsely claims 105 00:06:15.879 --> 00:06:20.490 to represent a legitimate company, the attacker could set up 106 00:06:20.490 --> 00:06:24.570 a fake website that appears secure due to their use 107 00:06:24.570 --> 00:06:28.045 of a valid certificate, deceiving users 108 00:06:28.045 --> 00:06:31.020 into sharing sensitive information 109 00:06:31.020 --> 00:06:34.200 like passwords or credit card details. 110 00:06:34.200 --> 00:06:37.410 A more dangerous scenario involves attackers 111 00:06:37.410 --> 00:06:40.920 obtaining certificates for domains that are designed 112 00:06:40.920 --> 00:06:43.260 to look like the legitimate ones. 113 00:06:43.260 --> 00:06:46.860 This is a practice known as domain squatting. 114 00:06:46.860 --> 00:06:51.860 Imagine a legitimate business called mysecurebank.com. 115 00:06:52.050 --> 00:06:55.140 An attacker might register a similar domain 116 00:06:55.140 --> 00:07:00.140 like rnysecurebank.com, where the RN can look like an M 117 00:07:02.550 --> 00:07:04.290 at a quick glance. 118 00:07:04.290 --> 00:07:07.260 If the attacker can obtain a valid certificate 119 00:07:07.260 --> 00:07:10.680 for the fake domain, users might not notice 120 00:07:10.680 --> 00:07:13.500 that slight difference in the domain names 121 00:07:13.500 --> 00:07:14.940 and trust the site 122 00:07:14.940 --> 00:07:18.510 because the browser shows a secure connection. 123 00:07:18.510 --> 00:07:22.389 This can result in users unknowingly entering sensitive 124 00:07:22.389 --> 00:07:26.460 information into an attacker's site leading 125 00:07:26.460 --> 00:07:29.610 to data theft or financial fraud. 126 00:07:29.610 --> 00:07:33.000 So to prevent these types of attacks, 127 00:07:33.000 --> 00:07:35.910 strict validation procedures must be 128 00:07:35.910 --> 00:07:39.330 in place before issuing certificates. 129 00:07:39.330 --> 00:07:42.750 In addition, certificate authorities should thoroughly 130 00:07:42.750 --> 00:07:46.080 vet the identity of the requesting party, 131 00:07:46.080 --> 00:07:50.100 ensuring they have legitimate control over the domain 132 00:07:50.100 --> 00:07:54.600 or organization for which the certificate is being issued. 133 00:07:54.600 --> 00:07:58.500 This can involve multiple layers of verification, 134 00:07:58.500 --> 00:08:03.360 including email validation, business registration checks, 135 00:08:03.360 --> 00:08:06.930 and direct contact with the organization. 136 00:08:06.930 --> 00:08:09.630 By ensuring that certificates are only issued 137 00:08:09.630 --> 00:08:13.920 to verified entities, certificate authorities 138 00:08:13.920 --> 00:08:17.588 can help prevent attackers from misusing certificates 139 00:08:17.588 --> 00:08:21.330 to conduct fraud or impersonation. 140 00:08:21.330 --> 00:08:26.040 Third, we have challenges in certificate revocation. 141 00:08:26.040 --> 00:08:29.671 Revoking a certificate is necessary when it is no longer 142 00:08:29.671 --> 00:08:34.002 valid, such as in cases of compromise, expiration 143 00:08:34.002 --> 00:08:37.530 or organizational changes. 144 00:08:37.530 --> 00:08:41.370 However, revocation can be complicated. 145 00:08:41.370 --> 00:08:43.920 One common issue is the delay 146 00:08:43.920 --> 00:08:47.040 in propagating the revocation information 147 00:08:47.040 --> 00:08:49.350 to all relevant systems. 148 00:08:49.350 --> 00:08:53.284 For example, if an employee leaves an organization 149 00:08:53.284 --> 00:08:58.069 and their digital is revoked, there may be a delay 150 00:08:58.069 --> 00:09:00.305 before all systems recognize 151 00:09:00.305 --> 00:09:04.080 that the certificate is no longer valid. 152 00:09:04.080 --> 00:09:08.550 This delay could allow the former employee to access systems 153 00:09:08.550 --> 00:09:11.850 that they are no longer authorized to use. 154 00:09:11.850 --> 00:09:15.933 Another challenge in certificate revocation is ensuring 155 00:09:15.933 --> 00:09:20.460 that all devices and systems regularly check 156 00:09:20.460 --> 00:09:22.860 for revoked certificates. 157 00:09:22.860 --> 00:09:25.635 If a system does not regularly update 158 00:09:25.635 --> 00:09:29.070 its certificate revocation list or check 159 00:09:29.070 --> 00:09:33.030 with an online certificate status protocol responder, 160 00:09:33.030 --> 00:09:38.030 it might continue to accept a revoked certificate as valid. 161 00:09:38.100 --> 00:09:41.220 For example, if a compromised certificate 162 00:09:41.220 --> 00:09:42.733 is not immediately recognized 163 00:09:42.733 --> 00:09:46.200 as revoked, an attacker could use it 164 00:09:46.200 --> 00:09:48.480 to access secure communications 165 00:09:48.480 --> 00:09:52.440 or resources leading to a data breach. 166 00:09:52.440 --> 00:09:55.170 To address revocation challenges, 167 00:09:55.170 --> 00:09:57.810 organizations should implement systems 168 00:09:57.810 --> 00:10:01.870 that support real-time certificate status checking, such 169 00:10:01.870 --> 00:10:05.880 as the online certificate status protocol. 170 00:10:05.880 --> 00:10:06.837 Regularly updating 171 00:10:06.837 --> 00:10:09.895 and distributing certificate revocation list is 172 00:10:09.895 --> 00:10:12.210 also important to ensure 173 00:10:12.210 --> 00:10:16.860 that all systems have the latest revocation information. 174 00:10:16.860 --> 00:10:21.540 By prioritizing timely and efficient certificate revocation, 175 00:10:21.540 --> 00:10:26.340 organizations can reduce the risk of unauthorized access 176 00:10:26.340 --> 00:10:30.000 and maintain the integrity of their PKI 177 00:10:30.000 --> 00:10:32.520 or public key infrastructure. 178 00:10:32.520 --> 00:10:37.380 Fourth and last, we have improper key management. 179 00:10:37.380 --> 00:10:41.550 Public and private keys must be securely stored 180 00:10:41.550 --> 00:10:44.340 and properly distributed to ensure 181 00:10:44.340 --> 00:10:48.540 that only authorized users have access to them. 182 00:10:48.540 --> 00:10:52.740 If the keys are improperly managed, they can be stolen, 183 00:10:52.740 --> 00:10:55.200 compromised, or misused. 184 00:10:55.200 --> 00:10:58.290 For example, if an organization fails 185 00:10:58.290 --> 00:11:02.280 to protect its private keys and they're stolen, 186 00:11:02.280 --> 00:11:04.155 an attacker could use these keys 187 00:11:04.155 --> 00:11:08.588 to decrypt sensitive data or impersonate the organization 188 00:11:08.588 --> 00:11:11.460 in encrypted communications. 189 00:11:11.460 --> 00:11:16.080 Another issue with key management is improper distribution. 190 00:11:16.080 --> 00:11:19.470 If private keys are accidentally shared 191 00:11:19.470 --> 00:11:21.480 with unauthorized parties 192 00:11:21.480 --> 00:11:24.150 or sent via insecure channels, 193 00:11:24.150 --> 00:11:27.060 they could be intercepted by attackers. 194 00:11:27.060 --> 00:11:28.170 For instance, 195 00:11:28.170 --> 00:11:30.870 if an administrator sends a private key 196 00:11:30.870 --> 00:11:34.920 via email without encryption, a hacker monitoring 197 00:11:34.920 --> 00:11:37.382 the email traffic could capture the key 198 00:11:37.382 --> 00:11:42.382 and use it to gain unauthorized access to secure systems. 199 00:11:43.170 --> 00:11:45.755 So proper key management practices can 200 00:11:45.755 --> 00:11:48.720 prevent these types of risks. 201 00:11:48.720 --> 00:11:51.810 To improve key management and distribution, 202 00:11:51.810 --> 00:11:56.520 organizations can use hardware security modules or HSMs, 203 00:11:56.520 --> 00:11:59.610 or other secure key storage solutions 204 00:11:59.610 --> 00:12:01.890 to protect private keys. 205 00:12:01.890 --> 00:12:04.887 Additionally, keys should only be distributed 206 00:12:04.887 --> 00:12:07.950 through secure encrypted channels. 207 00:12:07.950 --> 00:12:11.452 Finally, regular key rotation policies can 208 00:12:11.452 --> 00:12:15.810 also help reduce the risk of key compromise. 209 00:12:15.810 --> 00:12:20.400 So by implementing deliberate key management practices, 210 00:12:20.400 --> 00:12:22.693 organizations can maintain the security 211 00:12:22.693 --> 00:12:25.680 of the public key infrastructure 212 00:12:25.680 --> 00:12:29.640 and protect sensitive communications and data. 213 00:12:29.640 --> 00:12:33.147 So remember, public key infrastructure 214 00:12:33.147 --> 00:12:36.997 or PKI issues undermine the security 215 00:12:36.997 --> 00:12:41.790 of encrypted communications and digital certificates. 216 00:12:41.790 --> 00:12:46.350 These issues include misconfigured certificate authorities 217 00:12:46.350 --> 00:12:51.350 or CAs, expired or improperly issued certificates 218 00:12:51.540 --> 00:12:54.570 and challenges in certificate revocation 219 00:12:54.570 --> 00:12:57.300 and improper key management. 220 00:12:57.300 --> 00:13:00.810 Misconfigured certificate authorities can lead 221 00:13:00.810 --> 00:13:04.984 to the improper issuance of certificates, compromising trust 222 00:13:04.984 --> 00:13:08.790 and allowing unauthorized access. 223 00:13:08.790 --> 00:13:12.270 Expired or improperly issued certificates 224 00:13:12.270 --> 00:13:16.020 can prevent secure connections or enable attackers 225 00:13:16.020 --> 00:13:18.810 to impersonate legitimate entities. 226 00:13:18.810 --> 00:13:22.879 Next, challenges in certificate revocation can delay 227 00:13:22.879 --> 00:13:26.670 the recognition of compromise certificates, 228 00:13:26.670 --> 00:13:29.580 allowing unauthorized access. 229 00:13:29.580 --> 00:13:33.194 And finally, improper key management can result 230 00:13:33.194 --> 00:13:38.194 in the theft or misuse of keys leading to data breaches 231 00:13:38.220 --> 00:13:42.573 or unauthorized decryption of sensitive communications.