WEBVTT

1
00:00:00.000 --> 00:00:01.890
In this section of the course,

2
00:00:01.890 --> 00:00:04.830
we are going to discuss Hardware Security.

3
00:00:04.830 --> 00:00:07.530
The Hardware Security section of the course focuses

4
00:00:07.530 --> 00:00:10.260
on Domain 3: Security Engineering,

5
00:00:10.260 --> 00:00:13.320
specifically Objective 3.4,

6
00:00:13.320 --> 00:00:15.660
which states that given a scenario,

7
00:00:15.660 --> 00:00:16.493
you must be able

8
00:00:16.493 --> 00:00:20.880
to implement hardware security technologies and technique.

9
00:00:20.880 --> 00:00:24.450
Securing hardware systems begins with ensuring the integrity

10
00:00:24.450 --> 00:00:27.030
and reliability of every operation

11
00:00:27.030 --> 00:00:29.100
from the moment a device powers on

12
00:00:29.100 --> 00:00:31.170
to the protection of sensitive data.

13
00:00:31.170 --> 00:00:33.060
The integration of specialized hardware

14
00:00:33.060 --> 00:00:36.000
and encryption techniques plays a critical role

15
00:00:36.000 --> 00:00:37.980
in safeguarding this information

16
00:00:37.980 --> 00:00:40.170
and maintaining system resilience.

17
00:00:40.170 --> 00:00:41.910
As we go through this section,

18
00:00:41.910 --> 00:00:45.270
we will cover many topics related to Hardware Security,

19
00:00:45.270 --> 00:00:48.420
including Roots of Trust, Boot Options,

20
00:00:48.420 --> 00:00:52.200
Security Coprocessors, Self-encrypting Drives,

21
00:00:52.200 --> 00:00:55.590
Host-based Encryption, Self-healing Hardware,

22
00:00:55.590 --> 00:00:57.540
and Virtual Hardware.

23
00:00:57.540 --> 00:01:00.390
First, we will look at Roots of Trust.

24
00:01:00.390 --> 00:01:03.270
Roots of trust provide a trusted foundation

25
00:01:03.270 --> 00:01:06.660
for the secure operation of devices and systems.

26
00:01:06.660 --> 00:01:11.400
Roots of trust concepts include Trusted Platform Modules

27
00:01:11.400 --> 00:01:14.016
or TPMs, Virtual Trusted

28
00:01:14.016 --> 00:01:16.765
Platform Modules or VTPMs,

29
00:01:16.765 --> 00:01:20.310
and Hardware Security Modules or HSMs.

30
00:01:20.310 --> 00:01:23.580
A Trusted Platform Module is a physical chip

31
00:01:23.580 --> 00:01:25.590
that is installed on a motherboard.

32
00:01:25.590 --> 00:01:28.320
It securely stores cryptographic keys

33
00:01:28.320 --> 00:01:30.900
and performs cryptographic operations.

34
00:01:30.900 --> 00:01:34.410
A Trusted Platform Module is a hardware root of trust.

35
00:01:34.410 --> 00:01:38.460
A Virtual Trusted Platform Module extends this functionality

36
00:01:38.460 --> 00:01:40.470
to virtualized environments.

37
00:01:40.470 --> 00:01:43.050
It provides similar security features

38
00:01:43.050 --> 00:01:44.730
within virtual machines

39
00:01:44.730 --> 00:01:48.540
by emulating Trusted Platform Module capabilities.

40
00:01:48.540 --> 00:01:50.670
A Virtual Trusted Platform Module

41
00:01:50.670 --> 00:01:53.250
is also considered a root of trust.

42
00:01:53.250 --> 00:01:56.670
A Hardware Security Module is a dedicated hardware root

43
00:01:56.670 --> 00:01:59.880
of trust and is often a standalone appliance

44
00:01:59.880 --> 00:02:02.790
or specialized card designed to manage

45
00:02:02.790 --> 00:02:05.280
and protect cryptographic keys

46
00:02:05.280 --> 00:02:08.130
and perform cryptographic operations

47
00:02:08.130 --> 00:02:10.230
across multiple machines.

48
00:02:10.230 --> 00:02:13.710
A Hardware Security Module is not a chip installed

49
00:02:13.710 --> 00:02:17.340
on a motherboard, but rather a standalone device.

50
00:02:17.340 --> 00:02:20.790
In application, a physical server might utilize

51
00:02:20.790 --> 00:02:22.470
a Trusted Platform Module

52
00:02:22.470 --> 00:02:25.590
to secure its boot process, while virtual machines

53
00:02:25.590 --> 00:02:26.970
on the same server

54
00:02:26.970 --> 00:02:30.240
use Virtual Trusted Platform Module instances

55
00:02:30.240 --> 00:02:32.580
to secure their own boot processes.

56
00:02:32.580 --> 00:02:33.930
At the same time,

57
00:02:33.930 --> 00:02:36.570
a Hardware Security Module may be employed

58
00:02:36.570 --> 00:02:39.000
across multiple servers to manage

59
00:02:39.000 --> 00:02:41.670
and protect the master encryption keys

60
00:02:41.670 --> 00:02:44.490
for all physical and virtual systems.

61
00:02:44.490 --> 00:02:47.610
This combination of Trusted Platform Module,

62
00:02:47.610 --> 00:02:49.830
Virtual Trusted Platform Module,

63
00:02:49.830 --> 00:02:52.830
and Hardware Security Module employment ensures

64
00:02:52.830 --> 00:02:55.110
a unified root of trust that spans

65
00:02:55.110 --> 00:02:57.030
the entire infrastructure.

66
00:02:57.030 --> 00:02:59.670
Next, we will explore Boot Options.

67
00:02:59.670 --> 00:03:01.140
Boot options are methods

68
00:03:01.140 --> 00:03:04.560
and sequences that determine how a system starts

69
00:03:04.560 --> 00:03:06.420
and verifies its integrity

70
00:03:06.420 --> 00:03:08.970
before the operating system loads.

71
00:03:08.970 --> 00:03:12.720
Boot options include Secure Boot and Measured Boot.

72
00:03:12.720 --> 00:03:15.840
Secure boot ensures that each component loaded

73
00:03:15.840 --> 00:03:18.690
during the boot process, including boot loaders,

74
00:03:18.690 --> 00:03:20.520
operating system kernels,

75
00:03:20.520 --> 00:03:23.760
and drivers has a valid digital signature.

76
00:03:23.760 --> 00:03:26.880
By validating each boot process component,

77
00:03:26.880 --> 00:03:30.150
secure boot prevents unauthorized code from running

78
00:03:30.150 --> 00:03:31.860
during the boot process.

79
00:03:31.860 --> 00:03:33.780
Measured Boot, on the other hand,

80
00:03:33.780 --> 00:03:37.740
records cryptographic hashes of each component loaded

81
00:03:37.740 --> 00:03:41.760
during the boot process into a Trusted Platform Module

82
00:03:41.760 --> 00:03:45.690
to create a verifiable log of the boot sequence.

83
00:03:45.690 --> 00:03:48.660
Measured boot is used for attestation

84
00:03:48.660 --> 00:03:51.210
to detect boot file tampering.

85
00:03:51.210 --> 00:03:54.660
It does not prevent malicious boot files from loading.

86
00:03:54.660 --> 00:03:57.990
For example, a system might use secure boot

87
00:03:57.990 --> 00:03:59.910
to load the initial firmware

88
00:03:59.910 --> 00:04:01.860
and operating system loader,

89
00:04:01.860 --> 00:04:04.020
while measured boot logs the integrity

90
00:04:04.020 --> 00:04:06.840
of each step allowing security software

91
00:04:06.840 --> 00:04:10.830
to validate the boot process against known-goods states.

92
00:04:10.830 --> 00:04:14.490
After that, we will look at Security Coprocessors.

93
00:04:14.490 --> 00:04:15.960
Security coprocessors

94
00:04:15.960 --> 00:04:18.870
are specialized hardware components designed

95
00:04:18.870 --> 00:04:21.420
to perform cryptographic operations

96
00:04:21.420 --> 00:04:25.020
and store sensitive data in a protected environment.

97
00:04:25.020 --> 00:04:26.970
Security coprocessor concepts

98
00:04:26.970 --> 00:04:31.860
include CPU security extensions and secure enclaves.

99
00:04:31.860 --> 00:04:33.720
CPU security extensions,

100
00:04:33.720 --> 00:04:37.170
such as Intel's Trusted Execution Technology

101
00:04:37.170 --> 00:04:40.710
and AMD's Secure Encrypted Virtualization,

102
00:04:40.710 --> 00:04:43.920
provide hardware-based protection for critical processes

103
00:04:43.920 --> 00:04:47.940
and data by creating secure execution environments.

104
00:04:47.940 --> 00:04:51.540
A secure execution environment is a protected area

105
00:04:51.540 --> 00:04:53.940
within a computing system that isolates

106
00:04:53.940 --> 00:04:55.770
and secures sensitive data

107
00:04:55.770 --> 00:04:59.640
and processes from unauthorized access and tampering.

108
00:04:59.640 --> 00:05:03.000
Secure Enclave is a secure execution environment

109
00:05:03.000 --> 00:05:06.420
that operates separate from the main CPU

110
00:05:06.420 --> 00:05:09.000
and is specific to Apple hardware.

111
00:05:09.000 --> 00:05:12.990
Secure Enclave operates like CPU security extensions

112
00:05:12.990 --> 00:05:14.850
by isolating sensitive data

113
00:05:14.850 --> 00:05:17.430
and operations from the rest of the system.

114
00:05:17.430 --> 00:05:20.490
However, Secure Enclave is used primarily

115
00:05:20.490 --> 00:05:22.350
for storing encryption keys

116
00:05:22.350 --> 00:05:24.750
and performing secure transactions.

117
00:05:24.750 --> 00:05:29.130
In application, a system might use CPU Security Extensions

118
00:05:29.130 --> 00:05:32.100
to create a trusted execution environment

119
00:05:32.100 --> 00:05:34.560
for security-sensitive applications,

120
00:05:34.560 --> 00:05:38.670
while Secure Enclave ensures cryptographic keys used

121
00:05:38.670 --> 00:05:40.560
by these applications are stored

122
00:05:40.560 --> 00:05:42.180
and managed securely.

123
00:05:42.180 --> 00:05:44.940
This prevents unauthorized access,

124
00:05:44.940 --> 00:05:48.270
even if the main operating system is compromised.

125
00:05:48.270 --> 00:05:52.020
Next, we will explore Self-encrypting Drives.

126
00:05:52.020 --> 00:05:54.300
Self-encrypting drives are storage devices

127
00:05:54.300 --> 00:05:56.610
with built-in encryption capabilities

128
00:05:56.610 --> 00:05:58.470
that automatically encrypt

129
00:05:58.470 --> 00:06:02.730
and decrypt data as it is written to or read from the drive.

130
00:06:02.730 --> 00:06:04.860
Self-encrypting drives operate using

131
00:06:04.860 --> 00:06:06.660
an onboarding encryption engine

132
00:06:06.660 --> 00:06:08.790
to encrypt data transparently

133
00:06:08.790 --> 00:06:13.140
without requiring user interaction or additional software.

134
00:06:13.140 --> 00:06:16.020
Implementation of self-encrypting drives involves

135
00:06:16.020 --> 00:06:18.360
integrating encryption algorithms

136
00:06:18.360 --> 00:06:22.680
and a secure key management system directly into the drive.

137
00:06:22.680 --> 00:06:25.470
Self-encrypting Drives streamline deployment

138
00:06:25.470 --> 00:06:27.420
and provide better security

139
00:06:27.420 --> 00:06:30.330
than software-based encryption solutions.

140
00:06:30.330 --> 00:06:33.000
The advantages of Self-encrypting Drives

141
00:06:33.000 --> 00:06:36.480
include ease of use, consistent performance,

142
00:06:36.480 --> 00:06:39.480
and robust protection against data breaches.

143
00:06:39.480 --> 00:06:43.170
Following that, we will look at Host-based Encryption.

144
00:06:43.170 --> 00:06:46.230
Host-based encryption is encryption of data managed

145
00:06:46.230 --> 00:06:49.440
and controlled by the local operating system.

146
00:06:49.440 --> 00:06:53.010
Both Windows and Linux-based operating systems employ

147
00:06:53.010 --> 00:06:55.260
a type of host-based encryption.

148
00:06:55.260 --> 00:06:59.070
In Windows, file and volume level host-based encryption

149
00:06:59.070 --> 00:07:00.930
is offered by BitLocker.

150
00:07:00.930 --> 00:07:04.890
In Linux, the Linux Unified Key Setup or LUKS,

151
00:07:04.890 --> 00:07:08.130
is used to encrypt disc partitions and files.

152
00:07:08.130 --> 00:07:11.490
Next, we will explore Self-healing Hardware.

153
00:07:11.490 --> 00:07:14.160
Self-healing hardware has the capability

154
00:07:14.160 --> 00:07:17.070
to automatically detect, correct,

155
00:07:17.070 --> 00:07:20.040
and recover from its own faults or damage.

156
00:07:20.040 --> 00:07:23.700
Self-healing hardware concepts include efficiency,

157
00:07:23.700 --> 00:07:28.050
durability, sustainability, and innovation.

158
00:07:28.050 --> 00:07:31.140
Let's take a moment to define each of these concepts.

159
00:07:31.140 --> 00:07:34.410
Efficiency in self-healing hardware is achieved

160
00:07:34.410 --> 00:07:37.410
through mechanisms that enable quick fault detection

161
00:07:37.410 --> 00:07:41.520
and automated repair processes to minimize downtime.

162
00:07:41.520 --> 00:07:44.520
Durability is enhanced by the hardware's ability

163
00:07:44.520 --> 00:07:46.080
to recover from physical

164
00:07:46.080 --> 00:07:47.880
and logical failures,

165
00:07:47.880 --> 00:07:51.270
reducing the likelihood of a complete system failure.

166
00:07:51.270 --> 00:07:54.420
Sustainability in self-healing hardware is realized

167
00:07:54.420 --> 00:07:56.820
by extending the hardware's lifecycle

168
00:07:56.820 --> 00:07:59.760
and reducing the need for frequent replacements.

169
00:07:59.760 --> 00:08:03.630
Innovation in self-healing hardware drives the development

170
00:08:03.630 --> 00:08:07.200
of advanced diagnostic and repair technologies.

171
00:08:07.200 --> 00:08:11.160
In practice, modern self-healing server systems equipped

172
00:08:11.160 --> 00:08:14.190
with Redundant Array of Independent Discs

173
00:08:14.190 --> 00:08:17.820
or RAID configurations can automatically detect

174
00:08:17.820 --> 00:08:20.010
and rebuild failed disk drives,

175
00:08:20.010 --> 00:08:23.610
ensuring data integrity and system reliability

176
00:08:23.610 --> 00:08:26.280
without significant user intervention.

177
00:08:26.280 --> 00:08:29.280
Finally, we will look at Virtual Hardware.

178
00:08:29.280 --> 00:08:32.610
Virtual hardware is simulated hardware that is created

179
00:08:32.610 --> 00:08:35.190
and managed by hypervisor software

180
00:08:35.190 --> 00:08:38.730
to provide a virtualized hardware environment

181
00:08:38.730 --> 00:08:42.030
for running operating systems and applications.

182
00:08:42.030 --> 00:08:46.830
Virtual hardware concepts include scalability, efficiency,

183
00:08:46.830 --> 00:08:48.630
and cost-effectiveness.

184
00:08:48.630 --> 00:08:51.630
Virtual hardware enables scalability

185
00:08:51.630 --> 00:08:54.000
by allowing multiple virtual machines

186
00:08:54.000 --> 00:08:56.550
to run on a single physical server,

187
00:08:56.550 --> 00:09:00.780
dynamically allocating resources such as CPU, memory,

188
00:09:00.780 --> 00:09:02.760
and storage as needed.

189
00:09:02.760 --> 00:09:05.220
Efficiency in virtual hardware is achieved

190
00:09:05.220 --> 00:09:07.620
through optimized resource usage

191
00:09:07.620 --> 00:09:09.810
and the ability to quickly deploy

192
00:09:09.810 --> 00:09:12.840
and manage virtual environments without the need

193
00:09:12.840 --> 00:09:14.940
for physical hardware changes.

194
00:09:14.940 --> 00:09:18.570
Cost-effectiveness in virtual hardware is realized

195
00:09:18.570 --> 00:09:21.900
by reducing the need for physical hardware investments

196
00:09:21.900 --> 00:09:24.210
and lowering operational costs

197
00:09:24.210 --> 00:09:26.460
through consolidated infrastructure.

198
00:09:26.460 --> 00:09:29.490
For example, VMware's vSphere

199
00:09:29.490 --> 00:09:31.800
can create multiple virtual machines

200
00:09:31.800 --> 00:09:33.870
on a single physical server,

201
00:09:33.870 --> 00:09:37.710
efficiently scaling resources based on workload demands.

202
00:09:37.710 --> 00:09:39.720
By scaling virtual resources,

203
00:09:39.720 --> 00:09:41.370
hardware costs are reduced

204
00:09:41.370 --> 00:09:44.370
and overall system efficiency is improved.

205
00:09:44.370 --> 00:09:45.690
To finish things off,

206
00:09:45.690 --> 00:09:48.030
we'll take a short quiz to see what you learned

207
00:09:48.030 --> 00:09:49.920
during this section of the course,

208
00:09:49.920 --> 00:09:52.770
and we'll review each of those quiz questions fully

209
00:09:52.770 --> 00:09:55.890
to ensure you could explain why the right answers were right

210
00:09:55.890 --> 00:09:57.630
and the wrong answers were wrong.

211
00:09:57.630 --> 00:10:01.350
So, let's get ready to dive into Hardware Security

212
00:10:01.350 --> 00:10:02.850
in this section of the course!