Having Something To Hide
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61975 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023130 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Data storage deviceKernel (computing)Data storage deviceKey (cryptography)DiagramComputer animation
00:24
Physical systemDisintegrationKernel (computing)Information technology consultingDevice driverEncryptionPartition (number theory)Content (media)Virtual realityBlock (periodic table)Structural loadTable (information)CryptographyVolumeImplementationMiniDiscAreaBinary fileEmailData structureoutputBootingInformation securitySmart cardData storage deviceRandom numberMeasurementModul <Datentyp>Computing platformConditional probabilityData integrityMinimal surfaceSpacetimeDirected setIntelKey (cryptography)Computer hardwareRootLatent heatLoop (music)Core dumpEncryptionPhysical systemMechanism designBootingBinary codeVolume (thermodynamics)SpacetimeKey (cryptography)EmailLeakMeasurementComputer hardwareAreaSymmetric-key algorithmPeripheralMinimal surfaceLine (geometry)QuicksortAlgorithmLatent heatKernel (computing)Parameter (computer programming)MiniDiscType theoryLoginCryptographyCodeSource codeINTEGRALNumberCASE <Informatik>RoutingTheoryInterface (computing)PlastikkarteCuboidTransformation (genetics)Form (programming)Series (mathematics)Real numberSemiconductor memoryStandard deviationComputing platformLibrary (computing)State of matterAsynchronous Transfer ModeTelecommunicationMultiplication signDifferent (Kate Ryan album)Keyboard shortcutProjective planeData storage deviceLevel (video gaming)Distribution (mathematics)Random number generationFirmwarePatch (Unix)Service (economics)MotherboardBlock (periodic table)MultiplicationWindowBitInformation securityMappingMessage passingComputer fileTable (information)Data recoveryComputer animation
10:22
Table (information)Loop (music)Core dumpCryptographyResource allocationKey (cryptography)EncryptionSpacetimeMinimal surfaceInterface (computing)Integrated development environmentMaß <Mathematik>Physical systemMinimal surfaceKernel (computing)Interface (computing)Integrated development environmentCommunications protocolMereologyEncryptionSet (mathematics)Function (mathematics)LoginStructural loadKey (cryptography)Line (geometry)CryptographyExecution unitBootingSpacetimeLoop (music)Computer animation
12:30
Minimal surfaceSpacetimeInterface (computing)Key (cryptography)Integrated development environmentMaß <Mathematik>CryptographyComputer hardwareStandard deviationComputing platformRandom number generationTime domainPeripheralUniqueness quantificationAuthenticationModule (mathematics)Computer programBootingDirected setRead-only memoryRing (mathematics)ArmNormal (geometry)Kernel (computing)Patch (Unix)Software frameworkData storage devicePublic key certificateEntropie <Informationstheorie>Advanced Encryption StandardDevice driverRandom numberComputer configurationComputer hardwareExecution unitUniqueness quantificationBitDevice driverKernel (computing)Domain nameKey (cryptography)PlastikkarteProcess (computing)SoftwareConditional-access moduleNetwork topologyClient (computing)Asynchronous Transfer ModePower (physics)Integrated development environmentDefault (computer science)Minimal surfaceSource codeFront and back endsCoprocessorSeries (mathematics)Internet service providerCASE <Informatik>Formal verificationBootingCartesian coordinate systemRight angleFirewall (computing)ArmTime zoneBefehlsprozessorRun time (program lifecycle phase)Instance (computer science)Standard deviationProgrammable read-only memoryPublic key certificateSpeicherschutzCryptographyRandom number generationEntropie <Informationstheorie>FeedbackPatch (Unix)Semiconductor memoryData storage deviceElectric generatorChainForm (programming)State of matterType theoryFunctional (mathematics)EncryptionMultiplication signMeasurementInterface (computing)System on a chipRing (mathematics)Point cloudFerry CorstenFactory (trading post)Point (geometry)Computer animation
19:10
Entropie <Informationstheorie>Kernel (computing)Computer hardwareDevice driverRandom number generationAdvanced Encryption StandardRandom numberComputer configurationHuman migrationEncryptionKey (cryptography)AreaPatch (Unix)FeedbackDirected setAuthenticationCryptographyKernel (computing)RootPatch (Unix)MereologySlide ruleAuthenticationNetwork topologyKey (cryptography)Multiplication signFile systemException handlingPhysical systemComputer configurationConditional-access moduleSpacetimeBlock (periodic table)EmailAreaCASE <Informatik>FingerprintFormal verificationFeedbackPersonal identification numberHuman migrationComputer hardwareFerry CorstenBootingTheorySimilarity (geometry)Interactive televisionUtility softwareRange (statistics)CuboidEncryptionNumbering schemeProduct (business)1 (number)Computer animation
25:51
Program flowchart
Transcript: English(auto-generated)
00:05
Hello, our next talk is going to be by Ahmad about having something to hide. Thank you. Yes, so my name is Ahmad Fatoum, I'm an embedded Linux engineer with Pingotronix and thanks for attending my talk on having something to hide trusted key storage in Linux.
00:24
So Pingotronix, a company I work for is a German Linux consulting company we specialize in embedded systems, so all around embedded Linux consulting around drivers, bootloaders, kernel porting and in the course of one project I had occasion to get more familiar with kernel's trusted key subsystem, which I will talk about today.
00:43
But first I will talk about what we need to store these keys for. This is usually disk encryption, so if you install a new Linux distribution on many systems you already have whole disk encryption out of the box and it's just really a one-click affair, but what are the mechanisms underlying that?
01:07
That's usually the mcrypt. So the mcrypt is device mapper with the crypt target and what that does is that it maps physical devices to a virtual device and applies some transformation to it, in this case it's cryptography
01:23
and you see how that looks like in code at the end of the slide. You specify a range, you start from the first block, the number of blocks you specify that you want to use crypt, you specify your crypto parameters for example here it's AES and then you reference a crypto key
01:46
that you want to use for the symmetric encryption. So what you see here is a 32-byte long key with the name key and it's of type logon and in the line after that you see this key being added. And that's all you need to do, so to initialise your dmcrypt
02:03
then there is a dmsetup tool you can call and then you have the mscript running you can use this virtual device, just write to it and the physical device everything that will be written there will be encrypted with these parameters that you have set. Most people don't do this manually via dmsetup
02:23
but they have a wrapper around that that's usually cryptsetup with looks so looks is a desk encryption specification you see at the end how the header is laid out you have this binary header that's still there for compatibility then you have a JSON area that can describe these parameters
02:42
that we had in our dmsetup table like what sort of algorithm is used or what HMAC is used and then there is this keyslots area and in this keyslots area you have this volume key that was a 32-byte long key that we had
03:03
that key is what's actually used for crypto but if that leaks you have all your data encrypted with it so the idea with the mcrypt is with what cryptsetup and looks do is that you can have multiple key phrases
03:23
for example your normal key phrase that you always enter or a recovery key and then in turn you encrypt that volume key each time with a different key and that's stored in these keyslots area and that way you can have multiple pass phrases for the same volume
03:44
and yeah where does that pass phrase come from so it's usually entered by the user so in the initrd you are asked what's the pass phrase that you want and then you enter it you could be a bit more sophisticated and insert a USB stick that has a file that's the same code pass basically
04:01
you could insert a FIDO security key or a smart card but what all of these have in common is that the user is inserting or writing or you need user involvement and in my project it was an embedded system and we don't have really a user powering up the devices
04:20
and yeah we need some sort of automated solution for unattended boot and here is where trusted storage comes in so in the regular case the trusted storage is like the memory of the user or his USB stick but for an unattended boot
04:41
you need some on-chip or off-chip device that's appropriately secure that can hold the key such device is in many systems the TPM or the trusted platform would use this is an industry-wide standard it's also an international standard and it's mandated by Windows 11
05:02
which helps its adoption in a lot of modern systems because you couldn't boot Linux otherwise they are available as discrete devices as chips sometimes on like a breakout board for your motherboard but they can also be implemented in firmware
05:20
and TPMs have this standardized interface where you can talk to them and they provide you a lot of services what's interesting for us is that it has a random number generator built in so it has its own entropy source and gives you access to it and it holds a unique never disclosed key
05:41
and with this unique never disclosed key you can encrypt arbitrary data so instead of having a passphrase that you need to remember you could have an encrypted passphrase and then you pass it to the TPM and the TPM will decrypt it with this unique never disclosed key that it has inside
06:01
and then pass you the data in a decrypted form which you can then pass into the mcrypt or into crypt setup or whatever and you can make this even dependent on having reached a state that's an integrity measurement so each boot state could verify the boot stage after it
06:23
and then tell the TPM this measurement value and these measurement values are concatenated and hashed and kept in the TPM and you can configure the TPM to only release and only to decrypt data when it reaches that state
06:41
and when you configure it correctly the TPM would only decrypt your encrypted blob when you are indeed in that secure in that measured boot state that you want to be you can even bind it to a time so after a given time has elapsed
07:02
you can't access it anymore How does it look like in practice? The kernel has drivers for that that abstract away the different modes of communication it can be I2C, it can be SBI you don't need to worry about that in user space you have these device files
07:22
that provide you access there are user space libraries that wrap that and there is even a systemd support since I think a year and a half or so where you can enroll looks keys into TPMs it's very easy to set up
07:41
but whatever you do the common way of using this with looks has a common, you could call it issue that privileged user space has access to this key material so if you have seen there is this JSON area
08:01
where you could store stuff so you could store your encrypted key there and what would happen on boot is that prep setup or system decrypt setup or whatever would go there, it would get this encrypted key it would send it to the TPM the TPM would do its checks and see ok, I'm in the correct state it would decrypt this data
08:21
and then send it back to your user space and then your user space now has this passphrase which it could use to decrypt the encrypt key and then it would pass it into the kernel again so it's a real roundabout way to get the encrypt key into the kernel queuing so the idea behind trusted key was
08:42
why not directly decrypt the TPM secured key into the kernel queuing and reference it from there without involving user space at all and yeah, that has been implemented it was first added in 2010 the first kernel was released in 2011
09:00
it was originally TPM specific but the naming was held generic enough I think in hopes that it can be extended in future so the same patch series that added it added also encrypted keys so encrypted keys are keys that you can only observe from user space in encrypted form
09:23
that's how it should be so you tell the kernel generate a key for me and then when you try to export the key you only get it in encrypted form and then when you want to load it you give it the kernel in encrypted form and it will decrypt it but it will stay in kernel memory in decrypted form
09:41
and that's encrypted keys and trusted key additionally have a hardware route of trust so they use a TPM for doing the encryption and decryption so in theory you shouldn't be able to decrypt a trusted key to load it and have it decrypted on another system
10:00
than the one where you generate it on because on the other system you would have another trust source with its own unique key which is used for the encryption how does it look like in code? so it's basically the same line as we have seen before but instead of having a 32-byte long login key
10:22
we have a 32-byte trusted key here it's called KMK and to create it you can use a keyctl command you add a trusted key you don't specify the key material like we did with the login key because you can't do that you can just ask the kernel to generate you a 32-byte key
10:44
and then when you try to pipe it which is a command to pipe the key contents out unlike a user key which would just output the key material in plain text it would output the encrypted key
11:01
and that you can store wherever and use it on subsequent boots so what the rest does is it sets up a loop device and does the encrypt on it and write it works and then it reboots and then on the second boot if you were to create a new trusted key it would be completely different it would be generated randomly
11:22
and you want to use the keys that you have stored already which is what the blue line is doing it does add trusted KMK but instead of creating a new key it loads the key blobs that we have stored and with that you should be able to read back what you have written before
11:45
yeah, so that's how it works we have a way to do it in user space already and that's how it's usually done and not everyone agrees that sets strict advantages by doing it in the kernel but what was interesting to me
12:01
is that it is a very useful interface to represent much more than just TPMs because on modern system you can have off-ship secure enclaves basically a TPM that doesn't speak the TPM protocol and doesn't implement everything but it implements part of it you can have an on-ship trusted execution environment
12:23
you can have crypto units inside everyday socks very often you have like a crypto accelerator that also has access to a key that it could use for wrapping and unwrapping data and indeed in 2019 work started from Sumit Garg at Linaro
12:42
to generalize trusted keys and add key support in the first instance so what is T? T is also an API standard and what it's about it's having a hardware isolated environment where you can run trusted applications
13:02
on the same CPU where you execute your Linux but thanks to this hardware isolation normally armed trust zone if you do everything right and have firewalls in place and all that stuff you shouldn't be able to read the secure memory from your normal world which is Linux
13:22
and this trusted application can do basically everything you can have a trusted application that offers you a TPM and in that case you could just use trusted keys with TPMs but you can do basically anything it's software so you can just do random number generation in T you can do key sealing and unsealing with a hardware unique key
13:41
so that's available on some processors that when you are in the secure mode you have access to a key that you can never see from Linux which is unique and fused in and there are even people doing clock reset power domain support stuff in it because they don't want Linux to have access to these things
14:01
so if you are interested you can just grab the kernel tree for T client driver and see all the stuff that's there and what was interesting to me was the crypto unit inside the IMX SoCs it's called CAM by Freescale and we already have a CAM driver in Linux
14:22
it does random number generation, it does crypto acceleration it works a bit like a network card so it has these shared DMA rings where you push the jobs you want the CAM to do and then the CAM replies to you and you can do, as I said, crypto acceleration RNG
14:40
and it also has access to a one-time programmable master key that's fused by NXP in the factory and that's unique between devices that's the selling point and the CAM can use it for red blob generation which means it seals and unseals user supplied data using it
15:03
basically the same we have seen with the TPM and with T and it has black blob generation so TPMs are very slow and I don't know if they support crypto offloading but you probably don't want to do that if you want to do something quickly
15:21
but the CAM can do it much quicker and you can have this key never exit the CAM and use it for crypto inside the CAM you are of course limited to the crypto algorithm the CAM supports but the possibility is there if you don't want your key to even enter the kernel it should be all the time in the CAM itself
15:47
and yes, so why do we need that for? The common use case is certificate storage so you are a vendor and you need to call into your own cloud and you have client certificates for that
16:02
and you don't want someone to be able to desolder this eMMC and read it out and get access to your certificates and thus you decrypt the certificates and at runtime encrypt it into memory maybe normal memory, maybe unshipped memory, whatever and yes, we had many customers that needed something like that
16:25
and we had been carrying out of three patches for it in 2015 we sent it out the first time to get some feedback back then it was using the standard custom CFS interface and in the following years NXP tried to upstream their own new key types
16:47
to represent, to wrap this hardware functionality and finally in 2019 work began on generalizing trusted keys and it was finally merged in 2021
17:03
I also started then with implementing it for CAM and that support is now available since 5.19 and it's usable exactly the same way as with TPMs you can't do this measurement stuff because the CAM doesn't have support for that
17:20
but on NXP socks you would rather use their form of a verified boot so this unique key that's inside the CAM is only released when the sock believes it's in a high assurance boot state that means that the bootrom has verified the bootloader and then you are supposed to keep that chain of verification going
17:44
and bootloader verifies the kernel, the kernel verifies the initrd and so on some interesting tidbits while I upstreamed this series T and TPM both don't use the kernel entropy pool
18:01
for TPMs they always have a random number generator for T it was specified that they need to provide random number generation that's not something that I wanted to do for CAM because we have a perfectly fine CAM RNG driver not everyone was fine with it but eventually stubbornness prevailed
18:21
and you can now choose it for the existing backends as well you can specify trusted RNG equals kernel and then you can even for T or TPM use the kernel entropy pool if you want to use that the default is leaving it to the trust source to decide what it wants to do
18:43
and that's also useful for devices like on the i.MX6 ultra light light you can guess from the name it's supposed to be very lightweight and their crypto unit doesn't support an RNG so you rather want to use the kernel driver that's available
19:01
that does this a bit differently than have to do it in your own driver and what was also interesting hardware feature bits were broken on some variants so you can ask the CAM what features it supports and there are CAMs that support doers that say they have blob support but they lack AES support so they fail with an internal exception
19:23
when you try to use it because the sealing and unsealing is AES based but that's one more thing the kernel needs to take into account to work on these systems and that's also something I only learned about while getting review feedback
19:41
was not something I anticipated as you have seen NXP had different attempts on getting into the kernel and they applied that to the vendor tree they called it secure keys and during the upstreaming feedback I was asked if I wouldn't want to change my modifier key
20:03
to be compatible with the NXP kernel so people have an easier time migrating to it that was no problem for me it broke my sysfs interface but I needed a migration step anyway and it makes stuff easier for most of the users that want to switch so I did that
20:22
why did I need a migration step? because I was using looks before but looks doesn't have trusted key support so what I did is I used the encrypt directly I basically did the same thing that looks would be doing but only on the encrypt part and I would exclude the header you had seen in the first slides
20:44
you can specify the range of blocks that it should work on and then you can just cut out the looks area and do the encrypt directly and you need a one time import step because the first time you don't want to generate the trusted key randomly but you want to take the ones that you have already been using for years
21:00
of course in a new product you don't want that non upstream patch I linked there but in an existing product that's how you could do it old key blob, put into sysfs, get the plaintext key out keyctl imports and you have the new key blob we store both alongside so if the update fails for whatever reason you can fall back to the old system and use the old key blob and both work
21:23
finally what more is there to do? there is encrypted key support for the encrypt, encryptfs, evam and vdim there is direct key support, trusted key support without involving encrypted key for the encrypt and you can use encrypted keys future candidates would be fscrypt there has been attempts, one for the old key setup scheme
21:43
the second by me for the new setup scheme ubfs authentication also currently uses a logon key that could be changed to be a trusted or an encrypted key but these patches have died down look support would be awesome because with looks it just works out of the box
22:03
with the encrypt we still need to do it manually but that enables us to do it completely in the kernel without involving user space and yeah you don't really want user space messing with a DMA capable device that could just overwrite the kernel if you give it access so trusted keys was the correct solution for us there
22:21
and that concludes my talk and I would accept your questions if you have any thank you and we have some time for a few questions I have a question
22:46
are you aware of any way to kinder get this step of getting the secret from the hardware to automate that into the kernel as well so you don't need user space interaction
23:01
user space utilities my use case is mainly like the root file system and to forego using an init ramfs that needs to run a lot of commands so you could from the kernel command line similar like with d a minute also get the key
23:22
personally I would if I had that requirement I would consider doing it from the bootloader and then have the kernel read it off the kernel command line because the encrypted key blob there is nothing confidential about it so yeah in theory the kernel could accept it over the kernel command line but there is nothing like that currently
23:50
sorry I can repeat the question if it's too
24:04
is there a way to also combine these hardware keys with some pin and looks so you have to authorize yourself to the device that's not really how it's meant to be used
24:23
because the key material shouldn't exit the kernel and you directly reference the mcrypt key you insert the key in the kernel keyring and directly reference it so I don't know how to do it to easily factor in a user pin
24:41
there is a passphrase option? okay apparently there is a passphrase option that I need to look up when using trusted keys so thanks for the talk would it be possible to add a manual step
25:02
before communicating with a TPM for example a fingerprint scanner or anything like that is there a hardware and software option to combine the two verification steps?
25:24
you could so currently you need to have an initrd so in my case you have an initrd or I don't even have an initrd I don't use it for the root file system but if you were to use it for the root file system for example you could in the initrd first check that you have this that fingerprint is there
25:43
but there is no way to wire it in the kernel first this needs to happen, then that that's more of a policy thing that you would do in user space