WEBVTT

1
00:00:00.330 --> 00:00:01.320
In this lesson,

2
00:00:01.320 --> 00:00:04.331
we will learn about security properties.

3
00:00:04.331 --> 00:00:07.080
Security properties are realized

4
00:00:07.080 --> 00:00:10.920
through mutual authentication and forward secrecy.

5
00:00:10.920 --> 00:00:14.550
Mutual authentication is a security process

6
00:00:14.550 --> 00:00:18.930
where both parties in a digital conversation verify

7
00:00:18.930 --> 00:00:20.700
each other's identity.

8
00:00:20.700 --> 00:00:24.420
Forward secrecy, on the other hand is a property

9
00:00:24.420 --> 00:00:29.100
of cryptographic protocols that ensures the security of past

10
00:00:29.100 --> 00:00:33.600
and future sessions, even if a private key is compromised.

11
00:00:33.600 --> 00:00:36.420
Let's learn more about mutual authentication,

12
00:00:36.420 --> 00:00:38.130
and forward secrecy.

13
00:00:38.130 --> 00:00:41.430
First, we have mutual authentication.

14
00:00:41.430 --> 00:00:45.060
Mutual authentication is a security process

15
00:00:45.060 --> 00:00:48.810
that ensures both parties in a digital conversation

16
00:00:48.810 --> 00:00:53.810
verify each other's identity before any data is exchanged.

17
00:00:54.000 --> 00:00:58.020
This means that not only does the client confirm

18
00:00:58.020 --> 00:01:00.870
it is communicating with the correct server,

19
00:01:00.870 --> 00:01:04.710
but the server also verifies that it is interacting

20
00:01:04.710 --> 00:01:06.480
with the correct client.

21
00:01:06.480 --> 00:01:10.440
This two-way authentication helps establish trust

22
00:01:10.440 --> 00:01:12.720
on both sides of the connection,

23
00:01:12.720 --> 00:01:17.070
significantly reducing the risk of unauthorized access,

24
00:01:17.070 --> 00:01:21.690
or on path attacks where an attacker tries to intercept

25
00:01:21.690 --> 00:01:23.910
or alter communications.

26
00:01:23.910 --> 00:01:28.290
Imagine a scenario where you are entering a secure building.

27
00:01:28.290 --> 00:01:31.020
Normally, you would need to show your ID

28
00:01:31.020 --> 00:01:33.840
to the security guard to prove your identity.

29
00:01:33.840 --> 00:01:36.540
In mutual authentication however,

30
00:01:36.540 --> 00:01:38.640
the security guard would also need

31
00:01:38.640 --> 00:01:41.010
to show you their credentials to prove

32
00:01:41.010 --> 00:01:45.030
that they are a legitimate guard and not an imposter.

33
00:01:45.030 --> 00:01:49.380
Only when both of you have confirmed each other's identities

34
00:01:49.380 --> 00:01:53.370
do you continue with your interaction and gain access

35
00:01:53.370 --> 00:01:55.200
to the secure building.

36
00:01:55.200 --> 00:01:59.610
In this way, mutual authentication ensures the safety

37
00:01:59.610 --> 00:02:01.200
of both parties.

38
00:02:01.200 --> 00:02:05.430
In digital communication, this process often involves

39
00:02:05.430 --> 00:02:08.340
using digital certificates or keys.

40
00:02:08.340 --> 00:02:12.240
The client and a server exchange certificates confirming

41
00:02:12.240 --> 00:02:14.520
that they are who they claim to be

42
00:02:14.520 --> 00:02:18.420
before allowing any sensitive data to be shared.

43
00:02:18.420 --> 00:02:21.570
Mutual authentication is commonly used

44
00:02:21.570 --> 00:02:25.773
in secure environments like online banking, VPNs,

45
00:02:25.773 --> 00:02:29.760
and other systems where establishing trust is critical.

46
00:02:29.760 --> 00:02:33.990
By requiring both parties to prove their authenticity,

47
00:02:33.990 --> 00:02:38.760
mutual authentication provides a strong layer of security

48
00:02:38.760 --> 00:02:42.390
that protects against unauthorized access and ensures

49
00:02:42.390 --> 00:02:46.230
that the data remains confidential and secure.

50
00:02:46.230 --> 00:02:49.260
Second, we have forward secrecy.

51
00:02:49.260 --> 00:02:53.970
Forward secrecy, also known as perfect forward secrecy

52
00:02:53.970 --> 00:02:58.350
enhances data security in networks by ensuring

53
00:02:58.350 --> 00:03:02.520
that even if a session's encryption keys are compromised,

54
00:03:02.520 --> 00:03:05.880
past communications remain secure.

55
00:03:05.880 --> 00:03:09.240
It works by generating unique encryption keys

56
00:03:09.240 --> 00:03:13.050
for each session, which are never reused.

57
00:03:13.050 --> 00:03:17.400
This means that if encrypted traffic from today is captured,

58
00:03:17.400 --> 00:03:20.160
it cannot be decrypted in the future

59
00:03:20.160 --> 00:03:25.050
because the keys are specific to each session and unrelated

60
00:03:25.050 --> 00:03:27.510
to any other sessions keys.

61
00:03:27.510 --> 00:03:31.500
Similarly, if a key from today is compromised,

62
00:03:31.500 --> 00:03:35.580
it does not affect the security of data from previous

63
00:03:35.580 --> 00:03:39.780
or future sessions, assuming that forward secrecy

64
00:03:39.780 --> 00:03:43.320
is also implemented in future sessions.

65
00:03:43.320 --> 00:03:48.320
In earlier implementations of secure communications like SSL

66
00:03:48.570 --> 00:03:52.230
or secure sockets layer and TLS

67
00:03:52.230 --> 00:03:54.810
or transport layer security,

68
00:03:54.810 --> 00:03:59.810
a server's RSA key pair was used to secure the sessions.

69
00:04:00.030 --> 00:04:03.930
So the client would use the server's public key

70
00:04:03.930 --> 00:04:06.150
to encrypt a symmetric session key

71
00:04:06.150 --> 00:04:08.190
and send it to the server.

72
00:04:08.190 --> 00:04:12.690
The server would then use its own private key to decrypt

73
00:04:12.690 --> 00:04:16.230
the session key, which would then be used for the duration

74
00:04:16.230 --> 00:04:17.730
of that session.

75
00:04:17.730 --> 00:04:20.670
A major vulnerability in this approach

76
00:04:20.670 --> 00:04:24.510
was that if the server's private key were ever compromised,

77
00:04:24.510 --> 00:04:28.530
an attacker could decrypt all previously captured traffic,

78
00:04:28.530 --> 00:04:30.600
including the session keys,

79
00:04:30.600 --> 00:04:33.900
exposing all past communications.

80
00:04:33.900 --> 00:04:38.900
In 2014, the Heartbleed Bug highlighted this vulnerability.

81
00:04:39.480 --> 00:04:43.440
Heartbleed exploited a flaw in the implementation

82
00:04:43.440 --> 00:04:46.290
of the open SSL library,

83
00:04:46.290 --> 00:04:50.520
particularly in the TLS heartbeat extension,

84
00:04:50.520 --> 00:04:53.400
which is used to keep connections alive.

85
00:04:53.400 --> 00:04:56.790
Attackers could send malicious heartbeat requests

86
00:04:56.790 --> 00:05:00.330
tricking the server into leaking random chunks

87
00:05:00.330 --> 00:05:01.350
of its memory.

88
00:05:01.350 --> 00:05:05.940
This leaked memory could include sensitive information

89
00:05:05.940 --> 00:05:10.940
like private keys, user credentials, and other data.

90
00:05:11.040 --> 00:05:13.410
If private keys were exposed,

91
00:05:13.410 --> 00:05:16.470
any previously captured encrypted traffic

92
00:05:16.470 --> 00:05:18.690
could potentially be decrypted,

93
00:05:18.690 --> 00:05:22.170
assuming forward secrecy was not used.

94
00:05:22.170 --> 00:05:27.150
This incident underscore the importance of forward secrecy

95
00:05:27.150 --> 00:05:29.850
as it would have prevented attackers

96
00:05:29.850 --> 00:05:33.900
from decrypting past communications even if they obtained

97
00:05:33.900 --> 00:05:36.060
the current private keys.

98
00:05:36.060 --> 00:05:40.350
So perfect forward secrecy eliminates the risk

99
00:05:40.350 --> 00:05:44.280
of decrypting past or future sessions by ensuring

100
00:05:44.280 --> 00:05:47.520
that session keys are unique to each session

101
00:05:47.520 --> 00:05:52.200
and not derived from the server's long-term private key.

102
00:05:52.200 --> 00:05:55.860
That way, even if a session key is compromised,

103
00:05:55.860 --> 00:05:59.790
it cannot be used to decrypt other sessions.

104
00:05:59.790 --> 00:06:03.060
Key exchanges for perfect forward secrecy

105
00:06:03.060 --> 00:06:06.990
commonly use methods like the Diffie-Hellman key agreement,

106
00:06:06.990 --> 00:06:11.910
which does not expose the server's or client's private key.

107
00:06:11.910 --> 00:06:15.090
Making the encryption setup more secure.

108
00:06:15.090 --> 00:06:19.590
Forward secrecy is also commonly used in virtual private

109
00:06:19.590 --> 00:06:23.610
networks or VPNs, TLS 1.3,

110
00:06:23.610 --> 00:06:27.810
and Secure Shell or SSH protocols.

111
00:06:27.810 --> 00:06:32.040
Forward secrecy is also built into WPA3,

112
00:06:32.040 --> 00:06:35.130
the latest wireless encryption standard,

113
00:06:35.130 --> 00:06:40.130
through the simultaneous authentication of equals or SAE.

114
00:06:40.680 --> 00:06:45.680
SAE is a secure password based key agreement protocol

115
00:06:45.690 --> 00:06:49.980
that integrates forward secrecy to enhance security.

116
00:06:49.980 --> 00:06:54.780
The forward secrecy process generally involves four steps.

117
00:06:54.780 --> 00:06:59.160
First, both the client and server generate a pair

118
00:06:59.160 --> 00:07:03.990
of long-term public and private keys, which are validated

119
00:07:03.990 --> 00:07:07.770
through trusted channels such as a certificate authorities

120
00:07:07.770 --> 00:07:10.290
to ensure their authenticity.

121
00:07:10.290 --> 00:07:13.470
Second, the client and server agree

122
00:07:13.470 --> 00:07:15.750
on an ephemeral session key,

123
00:07:15.750 --> 00:07:19.530
using a key exchange method like Diffie-Hellman,

124
00:07:19.530 --> 00:07:24.530
and authenticate to each other using their long-term keys.

125
00:07:24.570 --> 00:07:28.950
Third, the client as the sender encrypts a message

126
00:07:28.950 --> 00:07:33.300
using the session key and a symmetric encryption algorithm,

127
00:07:33.300 --> 00:07:35.580
and sends it to the server.

128
00:07:35.580 --> 00:07:40.380
Fourth, the server as the receiver decrypts the message

129
00:07:40.380 --> 00:07:42.690
using the same session key,

130
00:07:42.690 --> 00:07:46.110
ensuring that the data remains confidential

131
00:07:46.110 --> 00:07:47.550
during transmission.

132
00:07:47.550 --> 00:07:51.540
This process is repeated for each new session,

133
00:07:51.540 --> 00:07:55.050
ensuring that even if a session key is compromised,

134
00:07:55.050 --> 00:07:58.080
only that session's data is at risk.

135
00:07:58.080 --> 00:07:59.820
All other session keys,

136
00:07:59.820 --> 00:08:03.270
whether past or future remain protected,

137
00:08:03.270 --> 00:08:05.940
maintaining the integrity and security

138
00:08:05.940 --> 00:08:08.700
of the overall communication.

139
00:08:08.700 --> 00:08:12.180
So remember, security properties

140
00:08:12.180 --> 00:08:17.040
such as mutual authentication and forward secrecy

141
00:08:17.040 --> 00:08:21.600
are essential for protecting data in digital communications.

142
00:08:21.600 --> 00:08:25.830
Mutual authentication is a process where both parties

143
00:08:25.830 --> 00:08:30.000
in a conversation verify each other's identities,

144
00:08:30.000 --> 00:08:31.950
ensuring that both sides

145
00:08:31.950 --> 00:08:35.850
are trusted before any data is exchanged.

146
00:08:35.850 --> 00:08:39.210
This two-way verification establishes,

147
00:08:39.210 --> 00:08:42.030
and secures communication channels

148
00:08:42.030 --> 00:08:46.800
and helps prevent unauthorized access and attacks.

149
00:08:46.800 --> 00:08:51.510
Forward secrecy, also known as perfect forward secrecy,

150
00:08:51.510 --> 00:08:55.620
enhances security by generating unique encryption keys

151
00:08:55.620 --> 00:09:00.620
for each session, where each session key is never reused.

152
00:09:00.840 --> 00:09:04.500
This means that even if a key is compromised,

153
00:09:04.500 --> 00:09:08.820
it cannot be used to decrypt past or future sessions.

154
00:09:08.820 --> 00:09:12.810
Safeguarding the integrity of all communications.

155
00:09:12.810 --> 00:09:15.210
Together, mutual authentication

156
00:09:15.210 --> 00:09:18.990
and forward secrecy provide a strong defense

157
00:09:18.990 --> 00:09:20.880
against potential threats,

158
00:09:20.880 --> 00:09:24.210
ensuring that data remains confidential,

159
00:09:24.210 --> 00:09:26.313
authentic, and secure.