Chrome OS hardware-backed security and verified boot 101 (Chrome University 2019)

Aug 24, 2023

Chrome OS hardware-backed security and verified boot 101 (Chrome University 2019)

Welcome to Chrome University, where you will learn the foundations of how Chrome works.

Check out this talk for an overview of basic security features of Chrome OS - user authentication, verified boot - and how hardware is used to support them.

Chrome University playlist → https://goo.gle/ChromeU
Subscribe to Google Chrome Developers → https://goo.gle/ChromeDevs

Content

2.61 -> remind everybody next 35 minutes are

6.3 -> going to be devoted to Chrome OS

8.13 -> Hardware back security and verified food

11.34 -> to remind you a little bit what we what

13.59 -> was touched in the previous presentation

15.42 -> there are certain principles in which

16.949 -> chrome was built and security is

19.079 -> definitely one of them the same applies

20.82 -> to Chrome OS there is no such definitive

23.609 -> source as there is for chrome like go

25.589 -> chrome but there are a couple of those

26.88 -> and I look at both and in both cases we

29.819 -> also have three to four principles that

32.189 -> Chrome OS is built on for some reason

34.53 -> we've dropped stability from what chrome

37.109 -> does we added smartness but security is

39.66 -> there so apparently security is still an

42.69 -> important feature of Chrome OS and

45.41 -> basically in this talk we are going to

48.41 -> dive a little bit deeper into how it is

51.51 -> a shield so if you disclaimers before we

53.37 -> start first will mostly be focused on

57.12 -> the traditional security aspects such as

60.329 -> using cryptography for protecting user

62.82 -> data and such not on other features

65.64 -> which also contribute greatly to

67.49 -> security such as the ability to auto

71.04 -> update Chrome OS reboot quickly which as

74.85 -> you might guess is very important for

76.32 -> keeping user is up to date and fixed and

79.02 -> all the exploits quickly but we're not

80.76 -> talking about that we're talking about

82.08 -> mostly cryptography and more than that

84.36 -> we're talking about how we use hardware

86.37 -> to ensure they're the right level of

88.65 -> security and again even though it is

91.02 -> about cryptography it is not a crypto

92.97 -> 101

93.57 -> it is not information security 101 it's

95.64 -> not the truss support from all the 101

97.56 -> so there is if you need that there are

101.1 -> better experts and like those are

104.07 -> separate talks which require much more

105.27 -> than 30 45 minutes and since we have

109.05 -> this limited times span this talk will

112.38 -> be oversimplified I'll try to be

113.91 -> conceptually correct but I will kind of

117.27 -> skim over some details because going

120.9 -> into too much details will just over

122.61 -> complicate things also there will be

125.19 -> more talks today at yeah today which

128.28 -> will also touch on things like

129.66 -> biometrics which is also ways how

132.15 -> hardware is used to provide security and

134.46 -> do user authentication Chrome OS

136.35 -> so if you're interested in that please

138.38 -> listen to those dogs as well what chrome

141.75 -> has used to do to provide an adequate

144.09 -> level of security for its users first

145.77 -> off it needs to make sure that whatever

147.84 -> is booted on the device is a verified

151.53 -> trusted image verified boot which we'll

154.26 -> touch on later is the ability of Chrome

157.32 -> as devices to check that it only boots

160.17 -> properly signed Chrome OS images that it

162.9 -> prevents running all the images with

164.91 -> known vulnerabilities for example and

167.28 -> with all that that it provides recovery

170.25 -> in the cases where were like those

172.59 -> preconditions are not met next thing

175.11 -> policy enforcement's so as it was just

177.9 -> touched in the previous talk Chromebooks

180.21 -> are very popular in the educational

182.49 -> space and the monitor prizes so

185.3 -> enforcing policies such as for example

188.31 -> preventing users going into a special

191.22 -> development mode where they can run

192.72 -> whatever on their devices is an

195 -> important feature of Chrome OS so policy

198.06 -> enforcement is there and we need to

200.04 -> somehow deal with that well the next one

202.53 -> is obvious is user authentication so

204.42 -> whatever user touches the Chromebook we

206.73 -> need to understand who they are and only

208.38 -> give them access that they are data also

210.87 -> we need to authenticate the user through

213.9 -> various means because currently the

216 -> users are using Chromebooks on tablets

217.94 -> which were entering passwords it's not

220.68 -> very convenient so we allow pins will

223.95 -> allow secure cards where are other

225.3 -> methods indication and all that should

226.83 -> be handled by kurama's system in user

229.11 -> data protection so obviously even if you

231.69 -> lose your Chromebooks you should be

233.52 -> reasonably sure that your data cannot be

236.37 -> stolen by whoever finds this device so

239.76 -> even at rest even you know when the user

242.19 -> is not there the data should be

243.63 -> protected and should be really Chrome I

245.43 -> should prevent attackers from stealing

248.19 -> your data if they somehow get access to

249.69 -> your hard drive for your device next

252.6 -> thing is well besides the operating

255.6 -> system itself with all those user

256.83 -> education transition requirements there

259.68 -> are also applications which run on top

261.18 -> and they have their own security needs

262.86 -> so they need to have some place where

265.71 -> they can put for example there are

268.5 -> cryptography keys that they used

269.94 -> sign making shoes with their servers or

272.43 -> encrypt communications of their servers

274.16 -> and then you have a secure place to put

277.68 -> all those keys in on the device and

279.42 -> again cromoz provides this and the last

284.28 -> probably not least of the feature that I

287.19 -> want to touch here is remote station the

290.85 -> ability of chroma has to prove to remote

293.01 -> servers what they're actually talking to

295.62 -> Chrome OS device and they more than that

298.05 -> the Chrome OS device of a specific

300.18 -> identity of like a specific remise

302.19 -> device if it's important for them from

303.78 -> us to a specific type if it's important

305.37 -> for them and Chrome OS in a specific

307.35 -> state such as for example running a

308.91 -> signed verified image if it is important

311.61 -> for those services all this is remote a

313.23 -> station and that's taken the last issue

316.8 -> that we're going to touch here so how

319.83 -> chrome else does it like we're all here

323.1 -> Google we know how Google does it right

325.58 -> now

326.79 -> in our case it's not machine learning

329.28 -> it's a hardware root of trust and Carlow

334.23 -> root of trust is basically a separate

336.47 -> hardware component sitting on the device

340.44 -> which is separate from the main CPU

341.79 -> separate from the main memory separate

343.23 -> from disk and flash available to the

345.78 -> main CPU which can encapsulate secrets

350.34 -> it provides in non-volatile storage for

352.2 -> those secrets and which can perform

354.75 -> crypt operations in a way which is tied

356.85 -> to this device so they can only perform

358.169 -> on this device on this on this module

360.39 -> and which can prove its identity to the

363.81 -> rest of the operations to the rest of

365.49 -> the system or to other servers out there

370.83 -> and there is like another statistic

373.98 -> ation that defines that type of devices

376.28 -> as the trusted platform module device is

380.55 -> defined by trusted computing group and

383.76 -> for many years

385.73 -> Chromebooks contains TPMS trust platform

389.7 -> audio devices sorry platform modules I

394.47 -> guess in them to perform to provide this

398.16 -> Hardware root of trust

402.26 -> capability and to route all the secrets

404.75 -> that cromoz uses inside them recently we

409.19 -> started doing even better so about two

413.9 -> maybe a little bit more years ago yeah

416.09 -> two and a half years ago more on

418.22 -> Chromebooks sorry using Google specific

421.31 -> chips for this purpose where which are

424.28 -> currently known under the trying to name

425.75 -> they used to be known on the under h1

427.31 -> name and this is the special security

431 -> chip built by Google which also provides

435.11 -> the hardware root of trust functionality

437.06 -> but compared to third-party TPMS we have

440.72 -> certain advantages that we can use for

443.33 -> Chrome OS purposes like they're obvious

446.87 -> because it's a Google designed and

448.97 -> Google magnifier like you go provide a

450.65 -> chip it's I have full control over the

453.56 -> firmware that runs on those chips it's

456.11 -> actually open source what this 99% of it

458.48 -> is it's open source so we know what goes

462.59 -> in there

463.55 -> we can quickly what we we can provide

466.19 -> preventing a third-party exploit to go

468.47 -> into there we can when we find bugs we

470.72 -> can make sure that the fixes are made

472.34 -> quickly and efficiently so that like the

476.39 -> same way if issues are found in the

478.49 -> Chrome OS the next update to get them

480.17 -> fixed the same way if issues are found

482.24 -> in it in this trust in this root of

485.75 -> trust firmware on the next update will

487.7 -> get them fixed and it also allows for

491.59 -> extensibility so even though for legacy

495.74 -> reasons those chips start with providing

498.95 -> a subset of trusted platform module

501.13 -> commands which can be sent for by

504.77 -> Cromwell

505.72 -> nowadays they do more than that so they

508.58 -> also serve as the second factor

510.17 -> authentication devices with a separate

511.7 -> set of commands that they provide they

513.56 -> also provide special capabilities for

517.51 -> users who need to log in with pins and

520.13 -> at the same time you need to make sure

522.11 -> that nobody can just guess through all

524.33 -> the you know combinations of a five

528.29 -> digit PIN and log in there very quickly

530.63 -> so all those things were added on top of

533.21 -> like a limited subset of

536.06 -> CPM commands that cromoz uses so having

541.43 -> said that so I've said that like Chrome

544.22 -> OS root of trust is rooted in this in

547.43 -> this hardware module which is true for

550.61 -> many cases but not for all them and you

553.22 -> may see a couple of cases in the next of

556.4 -> this presentation I will not be able to

558.62 -> talk about all the features that I

560.36 -> listed before but that will touch a few

562.16 -> of them like survey verified boot and

564.31 -> this is the one to remind again well we

567.29 -> want to boot only properly side Chrome

569.089 -> OS images and I want to prevent rollback

571.1 -> to images with known vulnerabilities so

574.61 -> it actually from the hardware root of

578.69 -> trust point of view it gives us a couple

580.4 -> of interesting features provided by this

582.529 -> hardware root of trust one of them is

585.25 -> so-called platform configuration

586.79 -> registers and platform cooporation

589.04 -> registers is actually a register like

592.04 -> you'll know like what the register is

593.33 -> which stores data but instead of and it

596.39 -> allows you to read this data but instead

598.49 -> of a write operation it provides a

599.87 -> special extended duration into there

601.52 -> which actually relies on using hashes

604.97 -> like sha-256 sha-512 if you know

608.74 -> cryptography basics which are the

613.16 -> important part the important thing about

614.51 -> them is they're like one-way functions

616.79 -> so if you know the original data it's

619.85 -> very easy to calculate the result of

622.07 -> applying this function of a and sha hash

624.89 -> to this data but going back is let's say

629.63 -> impossible what you can do is with with

632.93 -> those platform configuration registers

634.58 -> is to extend it which means you provide

637.49 -> some value and what it does it takes the

640.61 -> previous value stored in this register

641.92 -> takes the value that you provided

644.27 -> combined them and then calculates the

646.01 -> hash of them and store them back into

647.9 -> this register this way if you know what

651.74 -> operations would prefer what what extend

653.3 -> operations were performed or you think

655.67 -> you know what extend operations you can

657.5 -> also you could always verify that you

658.97 -> can by hand by hand outside of the

662.839 -> hardware root of trust you can

664.01 -> recalculate all those hashes

665.42 -> that's a simple operation you can always

666.62 -> do that and then read the PCL register

669.72 -> and compare what you calculated with

672.36 -> what start there this this way you will

674.61 -> know that the list of vibration that you

676.829 -> think you will perform is actually the

678.42 -> list of operations that this a lot of

680.639 -> trust the hardware security module saw

682.23 -> this platform configuration register

684.449 -> feature will be used by verified boot

686.22 -> and by other features used by cromoz

691.519 -> anyways I think I'll continue the second

695.31 -> feature is no no no tell around provided

698.459 -> by TP abs or security chips so as I said

702.959 -> like it provides us the hardware roots

705.839 -> of trust provides us a way to store data

707.55 -> on a separate hardware module in a way

710.879 -> that can ascertain only authorized

714.87 -> access to this data so what it means is

718.5 -> those chips provide region of memory and

721.199 -> a non-volatile memory that somebody can

723.779 -> serve data in and those who serve a that

726.269 -> they define special region spaces called

729 -> their and they provide special

730.589 -> attributes for those spaces which tell

732.81 -> that only somebody who provides a

735.509 -> certain password can read from this data

737.129 -> or only if the device in a specific

740.279 -> state such as one of the PC registers in

743.399 -> a spear contains a certain value you can

745.709 -> read the data from there all right data

747.059 -> from there and more and more and more

749.129 -> and more only once after reboot or only

751.62 -> before you call us or log function and

753.93 -> all this so those are MCS allow us to

756.809 -> provide an authorized access to the data

760.769 -> stored on the on on a TPM or a secure

762.809 -> module chip so now let's see what

766.92 -> verified boot actually does so it means

769.8 -> like the high level it's it's a pretty

772.259 -> simple thing there is there are several

775.91 -> parts of the software and firmware has

778.889 -> run on the on the Chrome OS device we

781.439 -> start with the read-only firmware which

784.139 -> sits in a read-only

785.809 -> space and protected by a special right

790.35 -> protection flag which you can only get

792.959 -> access either if you get a physical

795.3 -> access to the device or through a

797.189 -> hardware root of trust or through a

799.88 -> security the

802.45 -> read-only firmware that verifies the

805.66 -> readwrite firmware there is right part

807.639 -> of the firmware and it gets its image it

812.139 -> verifies its signature it checks that

815.74 -> the signature matches the key that it

817.24 -> has and only if it it matches that

819.85 -> inputs readwrite part of the firmware

822.76 -> does the same with kernel kernel does

824.889 -> the same with the root file system that

826.6 -> uses so if this chain in in this chain

830.32 -> like every next they have a look

832.149 -> previous stage verify the next stage and

833.949 -> only if all stages were verified like

836.199 -> with boots all the way to the kernel and

838.66 -> we run this operating system dig a

841.24 -> little bit deeper again we don't have

843.579 -> much time so there is a special block in

846.579 -> flash that stores the root key which is

849.459 -> used to verify the readwrite firmware

852.339 -> and it is right protected so nobody can

855.699 -> override it without special access to

857.29 -> the device the arrow from where guest is

861.04 -> flag then it decides on which of the two

863.68 -> versions and we need to be able to

865.42 -> update the orig where readwrite part of

868.029 -> the firmware in the field like with

870.1 -> every auto update with we should get for

872.38 -> your Chrome OS you may get not update

874.209 -> for your read/write part of the firmware

876.43 -> as well so it has two slots where those

880.69 -> are W parts are stored it picks the one

884.29 -> with the highest version and it also

886.3 -> checks if the version is not lower than

888.64 -> the minimal version it accepts it

890.74 -> verifies the signature it both said same

893.949 -> with the OS image and kernel there are

897.399 -> two kernel partitions currently and

899.98 -> cannot be read write firmware checks

901.99 -> which one is newer again verifies that

904.81 -> the image version is higher than the

908.819 -> known good threshold that is provided

911.44 -> somewhere for this for this our W

913.6 -> firmware gets the root filesystem for

916.569 -> for for the same current booster and so

919.36 -> on so for what it allows us to do is to

922.899 -> have several modes in which Chrome a

927.519 -> spot and the typical like the one where

931.149 -> chrome has devices are most typically

932.68 -> boolean is the verified normal mode

934.63 -> where all those

936.22 -> stages are performed and all those

938.2 -> checks are performed and if something

940.18 -> doesn't check out if for example the

943.51 -> read-only firmware is not able to find

946 -> the sign readwrite firmware on the disk

948.01 -> it will not be able to build it and it

950.74 -> will go into recovery mode which will

953.44 -> allow you to recover the device from

955.39 -> this abortion state same thing will

957.55 -> happen if there are some hardware issues

959.83 -> during the boot process now in addition

962.62 -> to that we allow the users of

965.32 -> Chromebooks to get a kind of better

968.41 -> access to their device if they want to

971.23 -> experiment if you need to run something

972.73 -> special if you want to run a different

974.8 -> operating system on this device after

976.36 -> all it's their device if it is their

978.25 -> device they can enter a special

980.14 -> developer mode it can allow you to build

982.3 -> a different image down set special flags

984.76 -> in flash that allow you to boot from USB

986.62 -> in addition to that like how you do that

989.83 -> well you go to recovery mode if you

992.65 -> remember if there is an error if we are

994.81 -> not able to boot a properly silent image

998.38 -> we go into recovery mode you could also

1000.12 -> trigger go into recovery mode manually

1002.28 -> if you want to if you need to recover or

1004.32 -> if you need to switch to boot in

1005.64 -> developer mode and in this case it's the

1008.67 -> read-only part of the former that

1010.02 -> recognizes this request to go into

1011.94 -> recovery which will not boots a read

1015.26 -> read/write part of the former but

1018.09 -> instead will boot the specialist side

1021.72 -> recovery kernel images only and those

1024.81 -> recovery images will be able to update

1027.96 -> the operating system image running on

1030.75 -> your device why do we need a special

1033.15 -> mode for that because normally if you

1035.88 -> remember what I told about the use of

1038.97 -> the secure module we have PCR registers

1041.34 -> and we have inverse bases mmm spaces are

1044.82 -> used to store those minimum threshold

1047.52 -> versions of firmware and Chrome OS

1050.25 -> kernel which are allowed to put on as

1052.26 -> devices those these are those anti

1055.05 -> rollback features that we have so if you

1056.97 -> know that versions up to a certain one

1059.12 -> has an issue it has some non

1062.37 -> vulnerability the he was vulnerable or

1067.62 -> something like that we can set this

1069.54 -> threshold

1070.11 -> one will not be able to boot this

1071.429 -> version and those words in a sort in CPM

1073.86 -> or security chip and garam and before

1078.6 -> booting the read/write like when ro

1081.87 -> boots read/write part of the form where

1083.82 -> it locks this and where I'm from

1086.039 -> overriding by by any subsequent software

1091.08 -> that runs on this device same thing when

1092.94 -> we rewrite part of the former boots the

1095.88 -> kernel it locks first the atmarama space

1098.1 -> which divides the for internal version

1099.96 -> from being updated until the device is

1102.419 -> rebooted so in recovery mode we don't

1105.029 -> lock those spaces

1105.99 -> we'll have to recover image especially

1107.61 -> sign recovery image to overwrite them if

1109.62 -> needed we are let the recovery image to

1112.11 -> do other things on the device we don't

1113.76 -> like to lock the device from this image

1115.38 -> and that allows you it to do certain

1117.48 -> things and allows it to restore it to

1119.659 -> good state so this is how it works in

1124.559 -> addition to that as a part of this whole

1127.38 -> process

1129.419 -> the former sets this state in which it

1131.76 -> but it was it the recovery mode was the

1133.5 -> development mode was the normal mode

1136.019 -> into one of the PCR registers that we

1138.419 -> talked about and this way the software

1140.82 -> that runs after that will be able to

1143.309 -> verify in which mode this device was

1146.159 -> booted and this way the software it runs

1148.169 -> after that will be able to protect their

1149.82 -> data from which they use again a

1153.269 -> hardware root of trust to store from

1155.99 -> being read in the wrong mode for example

1158.49 -> if they if they have a key which they

1160.62 -> want to use to say decrypt user data

1163.26 -> only one device is boot in a normal mode

1165.63 -> they can create this key on the TPM side

1169.529 -> and tied to a specific value of this PCR

1172.679 -> zero register and only if winner in

1175.289 -> verified in the normal mode this key

1177.75 -> will will work and will allow to decrypt

1179.88 -> user data if we put an in developer mode

1181.799 -> no this key will not work you will not

1184.11 -> be able to do great so that's very quick

1187.23 -> very quickly what the verified boot is

1190.11 -> now the core of cremona security user

1194.159 -> authentication data protection and again

1197.34 -> it's pretty simple in terms of what it

1199.5 -> needs to do it needs to check user

1201 -> passwords or other forms of

1202.409 -> communication and them

1204.15 -> provide access to the user data only if

1207.27 -> the right application was provided how

1210.84 -> does it do it so it encrypts user data

1213.84 -> and then can encrypt it with user

1215.82 -> specific keys and like I will describe

1217.95 -> how exactly it does it in a moment it

1220.47 -> also includes certain system data for

1222.75 -> example all the system logs are stored

1225.33 -> on a specially encrypted partition

1226.679 -> encrypted with a system level key

1228.83 -> because those logs may include some of

1232.26 -> your PI data data just by chance it may

1235.38 -> include some IP addresses that you

1237.24 -> accessed it may it may include some

1239.58 -> other information that can be used to

1241.11 -> determine what you were doing on this

1242.49 -> device or what this device is this way

1245.1 -> we product those system level data as

1249.6 -> well in case somebody grabs your

1251.61 -> Chromebook and Ivan gets access to a

1253.11 -> disk but user data is also protected

1257.07 -> with when user kids and for that we use

1260.84 -> Hardware bound keys basically those are

1263.13 -> the keys which are stored inside the TPM

1265.53 -> inside the secure chip does anybody here

1268.74 -> know what cryptographic keys are and how

1271.23 -> they used do we need that you've

1272.669 -> refreshers do we need any pressures or

1278.22 -> can I expect we can continue so

1282.95 -> basically a crypto key is something that

1286.53 -> allows you that has two parts private

1290.37 -> and public part if we are talking about

1292.35 -> the symmetric keys and that's what

1293.88 -> working about here and only a certain

1297.84 -> entity knows the private part and

1299.46 -> everybody else knows the public part and

1301.89 -> that allows you to do two things

1303.179 -> dependant of you talking about signing

1305.52 -> keys or decryption keys like anybody who

1309.21 -> with decryption keys anybody using the

1311.58 -> public key can encrypt the data but only

1313.919 -> the party that knows the private key

1315.24 -> that can decrypt this data with signing

1317.82 -> it's the opposite anybody who I mean

1322.77 -> only the party that knows the private

1324.6 -> key can sign it this data meaning that

1327.12 -> it can attach a signature to the data

1330.12 -> that it sounds like

1334.92 -> and the users of this data will be able

1337.44 -> to anybody who has the public you will

1339.45 -> be able to verify the validity there are

1342.03 -> things in this city of this data by

1343.74 -> checking the signature and verify

1345.93 -> another it matches what they can

1347.49 -> computer they they can see with the

1349.29 -> public key so with hardware root of

1354.09 -> trust we can put those keys into the

1356.85 -> separate hardware component into secure

1360.15 -> module so basically we can ask a secured

1363.12 -> module to generate a new key pair

1365.54 -> consisting of private public parts and

1367.89 -> this point is stored only on this secure

1369.84 -> module nobody else can see it it just

1372.51 -> generated it and provided some handle to

1374.46 -> use it then we can ask you to sign with

1377.7 -> this key for example and again this

1379.59 -> private key never leaves the hardware

1381.87 -> chip you provide the data you get back

1384.03 -> the signature or you can have to decrypt

1386.34 -> it with this private part or you can ask

1388.77 -> it to get back the public part to you so

1391.08 -> you can provide it to other users we

1392.4 -> need to validate your signatures off you

1393.9 -> need to encrypt the data so you can

1395.52 -> decrypt it so that's in essence what

1397.59 -> those keys are and again as with envy

1400.89 -> ROM spaces in TPM and secure chips those

1404.64 -> keys have attributes assigned to them

1407.28 -> which allow you to provide some

1408.87 -> requirements for who can use those keys

1410.85 -> only those who know the password only in

1414 -> a specific device state as I already

1415.26 -> mentioned about em many more other

1418.04 -> authentication policies are available

1420.15 -> out there but again we're not go into

1423.69 -> too many details here so how do we use

1426.57 -> those keys for example for user data

1428.48 -> every home directory for user on cromoz

1431.67 -> is stored in an encrypted file on a file

1435.48 -> system

1435.93 -> when a user logs in this file is mounted

1439.53 -> as a partition as a home directory for

1442.44 -> this user the key which is used to

1445.47 -> decrypt this file one Mountain it is

1449.06 -> it's a software key itself stored on

1452.58 -> disk an encrypted format the key to

1454.98 -> encrypt this key is provided by the

1457.53 -> former and by the user password so let

1460.59 -> me go into a little bit more details it

1462.27 -> will be all clear from this point on so

1464.78 -> let's say we have this encrypted user

1467.22 -> directory

1468.389 -> when the user first logs in and has an

1470.609 -> empty director we created and we create

1472.679 -> a random key which encrypts it it's

1476.429 -> completely random it's not tied to any

1478.289 -> TPM it's not tied to anything then we

1480.659 -> use this key to encrypt the user data

1482.549 -> and now we have the encrypted user file

1484.499 -> which we will be able to decrypt it with

1486.659 -> this key on this slide you will see this

1489.239 -> is the default key set is what we use to

1492.289 -> encrypt and decrypt the the user home

1496.109 -> directory and we use the wolf key set

1499.679 -> key vkk in the second part in a low part

1502.889 -> of the slide to encrypt or decrypt this

1506.249 -> encrypted wall kiss app now this work is

1508.169 -> set and store it in a encrypted form on

1510.029 -> on this so we have this random key that

1512.899 -> encrypts user data now we generate yet

1516.119 -> another key another random key which

1519.599 -> encrypts that key in turn and then we

1523.709 -> send this key through a couple of

1525.179 -> operations first we send it through we

1527.759 -> encrypt it with a TPM key so this

1530.849 -> Hardware back key we encrypt that key

1533.19 -> with it and we get a new blob of data

1535.109 -> basically out of it and then again we

1537.869 -> encrypt it with a user password there

1540.359 -> actually something derived from user

1541.829 -> password so when the user typed in their

1543.509 -> types in their password we again through

1546.989 -> a number of hashes and key duration

1548.789 -> functions generate the key and again in

1551.879 -> the deterministic way so that every time

1553.709 -> user types this password the same key

1556.409 -> will be generated out of that and we use

1558.57 -> this key as a second stage 2 now encrypt

1561.809 -> the blob which came out of the TPM and

1563.7 -> then store this this file on disk this

1566.07 -> blob on disk so when the user logs in

1569.519 -> they provide their password this key

1572.009 -> generated we read the file

1573.539 -> they encrypted wall key set key file

1575.669 -> from disk we apply this key to it we'll

1579.509 -> get the value we were we then send this

1581.729 -> blob to a security chip

1584.159 -> decrypt with that get another get

1586.799 -> another key and then we apply that key

1588.45 -> to a file on disk where the vault key

1591.659 -> set is stored and this work is set to

1594.179 -> none apply to the user home directory so

1597.029 -> that's a rough idea how are encrypting

1601.289 -> user data

1602.16 -> here works what it allows us to do first

1605.25 -> it allows us to tie encrypt user data to

1607.95 -> this device so only when they have

1610.14 -> access to this CPM you will be able to

1612.51 -> decrypt the blob which came from the

1615.09 -> encrypt world kisser key and it also

1617.64 -> allows you to try to user passwords only

1619.62 -> only somebody who knows the user

1621.24 -> password will be able to send this key

1624 -> fro for this whole sequence and get the

1626.43 -> mounted partition at the end so this way

1629.96 -> if somebody steals your device they will

1633.42 -> not be able to do it or if somebody

1635.79 -> copies your data to a different computer

1638.13 -> and then throws like machine power in

1640.95 -> order to cycle through all the possible

1643.53 -> passwords they will not be able to do

1644.76 -> that because they will actually it's not

1646.62 -> the password that they need to crack

1648.69 -> they also need to crack the key which is

1651.36 -> stored in a TPM which is a marker a much

1653.67 -> harder thing to do so this is what we do

1657.81 -> of course in reality it is much more

1659.64 -> complex and I will skim over those

1661.26 -> things I guess since we ran out of time

1663.39 -> so these are the three schemes which are

1666.6 -> used in Chrome OS in reality and they're

1670.14 -> more complicated because you need to

1671.94 -> worry about multiple things including

1674.76 -> what if your TPM has a backdoor

1677.09 -> including many other things so we need

1679.68 -> to balance protection from the TPM and

1683.49 -> with the TPM and just but basically it's

1688.8 -> the same idea and I will not go for this

1690.69 -> for this list at the moment so why this

1693.3 -> complicated scheme why we have like

1694.92 -> those two levels like the second level

1696.99 -> is more or less clear so we need to

1698.88 -> protect both with the security and with

1700.68 -> the user password but why do we need to

1702.81 -> generate the intermediate key and then

1705.48 -> encrypt it with another key the reason

1708.03 -> is because we can have multiple

1710.16 -> authentication multiple authorizations

1712.17 -> for the same user it can be password can

1714.24 -> be opinion can be something else this

1717.03 -> way we generate a single key that it

1719.58 -> creates a user directory but we can have

1721.38 -> a multiple secondary keys which you

1723.39 -> could encrypt that key and one of one of

1726 -> them can go through a password one of

1728.34 -> them can go through some other form of

1730.1 -> authorization like a pin that the user

1732.57 -> provides and again those things that we

1735.54 -> shall just

1735.929 -> here those are just for password for

1738.809 -> pins a different workflow is used for

1741.69 -> smart cards a different workflow is used

1743.999 -> but eventually they get to the same key

1745.83 -> we should then apply it to the user

1746.97 -> directory and allows the Mount

1748.31 -> [Music]

Source: https://www.youtube.com/watch?v=iO6cb90WiQ4